Date: Wed, 29 Feb 2012 13:00:11 -0500 From: Jason Hellenthal <jhellenthal@dataix.net> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-current@freebsd.org, jb <jb.1234abcd@gmail.com> Subject: Re: negative group permissions? Message-ID: <20120229180010.GA93342@DataIX.net> In-Reply-To: <1330535893.1023.49.camel@revolution.hippie.lan> References: <loom.20120228T155607-690@post.gmane.org> <20120228162447.GB58311@mech-cluster241.men.bris.ac.uk> <20120229072458.GA95427@DataIX.net> <20120229085716.GA66484@mech-cluster241.men.bris.ac.uk> <loom.20120229T111136-48@post.gmane.org> <loom.20120229T141955-30@post.gmane.org> <1330527621.1023.27.camel@revolution.hippie.lan> <loom.20120229T171016-473@post.gmane.org> <20120229164115.GB64201@DataIX.net> <1330535893.1023.49.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 29, 2012 at 10:18:13AM -0700, Ian Lepore wrote: > On Wed, 2012-02-29 at 11:41 -0500, Jason Hellenthal wrote: > > > > On Wed, Feb 29, 2012 at 04:18:45PM +0000, jb wrote: > > > Ian Lepore <freebsd <at> damnhippie.dyndns.org> writes: > > > > > > > ... > > > > It's not a > > > > directory or executable file in the first place, so making it executable > > > > for everyone except the owner and group is not some sort of subtle > > > > security trick, it's just meaningless. > > > > ... > > > > > > Is it meaningless ? > > > > > > Example: > > > # cat /var/spool/output/lpd/.seq > > > #! /usr/local/bin/bash > > > touch /tmp/jb-test-`echo $$` > > > > > > # ls -al /var/spool/output/lpd/.seq > > > -rw-r----x 1 root daemon 54 Feb 29 17:05 /var/spool/output/lpd/.seq > > > # /var/spool/output/lpd/.seq > > > # > > > # ls /tmp/jb* > > > /tmp/jb-test-61789 > > > > > > # chmod 0640 /var/spool/output/lpd/.seq > > > # ls -al /var/spool/output/lpd/.seq > > > -rw-r----- 1 root daemon 52 Feb 29 17:11 /var/spool/output/lpd/.seq > > > # /var/spool/output/lpd/.seq > > > su: /var/spool/output/lpd/.seq: Permission denied > > > # > > > > > > > Giving execute bit to others by security means to allow others to search > > for that file and find it. If its not there then the process created by > > current user will not be able to read the file since they are not part > > of the daemon group. I would assume that sometimes the contents of .seq > > was judged to be insecure for whatever reason but judged that a user > > should be able to still in a sense read the file without reading its > > contents. Negative perms are not harmful. > > > > I do suppose a 'daily_status_security_neggrpperm_dirs=' variable should > > be added here to control which directories are being scanned much like > > chknoid. > > > > The exec bit's control over the ability to search applies to > directories, not individual files. For example: > > revolution > whoami > ilepore > revolution > ll /tmp/test > -rw-r----x 1 root daemon 0B Feb 29 07:37 /tmp/test* > > The file is 0641 and I'm not in the daemon group; I can list it. > The issue is not with listing the file. Setting the execute bit on a file where there is only a read bit higher up allows for the calling process to read the contents and noone else. This is special and not a flaw. > Again, the problem here seems to be the use of 0661 in the lpr program, > not the idea of negative permissions, not the new scan for the use of > negative permissions. It's just an old bug in an old program which used > to be harmless and now is "mostly harmless". Instead of trying to "fix" > it by causing the new scan to ignore it, why don't we fix it by fixing > the program? (I'd submit a patch but it's a 1-character change -- it's > not clear to me a patch would be easier for a commiter to handle than > just finding and changing the only occurrance of "0661" in lpr.c.) > It was intentional and not a flaw. This file should be readable by the calling process and noone else. This is the way permissions work. -- ;s =;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120229180010.GA93342>