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

Andreas Gruenbacher
2007-05-26T11:46:53Z

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