Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file.  I  
> > can imagine (although it is a bit of a stretch) allowing a set of  
> > users access to gunzip but not gzip (or the other way around).
> 
> That is a COMPLETE straw-man argument.  I can override your "check"  
> with this absolutely trivial perl code:
> 
> exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";

The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so 
this confirms that the value of argv[0] is arbitrary. Well great, we already 
knew.

> Pathname-based checks are pretty fundamentally insecure.

Please don't mix apples and pears. Some utilities change their behavior based 
on argv[0], which indeed is not secure. It doesn't have to be for those 
utilities' needs. This is different from pathname-based access control, which 
is based on the pathname of the binary actually being executed.

AppArmor does not look at argv[0] for anything, and doing so would be insane. 
So please don't jump to the wrong conclusions.

You can have application-level argv[0] checks in the binary that is hardlinked 
to /bin/gzip, /bin/gunzip, /bin/zcat. At the same time, the kernel knows 
which of these three versions it is executing, so from that point of view, 
they could be as well be separate copies, and different policy can be defined 
for each one of them. (This is ignoring the fact that for small utilities 
like gzip, profile inheritance is usually more useful than defining separate 
profiles.)

Thanks,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/