Re: negative group permissions?

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.

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.)

-- Ian