Re: Pass struct vfsmount to the inode_create LSM hook

Andreas Gruenbacher
2007-05-26T13:41:42Z

On Saturday 26 May 2007 14:09, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > 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.
> >
> > AppArmor does not look at argv[0] for anything, and doing so would be
> > insane. So please don't jump to the wrong conclusions.
>
> I agree that argv[0] checking is different from pathname-based access
> control or label-based access control, but I want to say argv[0] checking
> is still needed.
>
> If you don't check argv[0], an attacker can request everything like
>
> exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
> exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";
>
> if /bin/ls and /bin/cat and /bin/rm are hardlinks of /sbin/busybox (e.g.
> embedded systems).
>
> Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> passed to execve().

So you are indeed trying to control the value of argv[0]? Well, good luck with
that, but it's totally insane. You are guaranteed to break some applications.
AppArmor is not going to go down that route.

If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary
(rather than symlinks), different profiles could be used for each of them.
The cat profile could have no more than read access anywhere, so this would
prevent it from removing files. That's an effective access control mechanism.

Conspiring with busybox in the kernel and making it do the right thing (and
just that) at the application level is not an effective security mechanism:
the kernel would still allow busybox to do anything, and there could be bugs
in the application, busybox's calling convention could change to allow more
than one command per invocation (e.g., ``cat /etc/shadow ; rm /etc/shadow''),
etc.

Andreas