linux-kernel - Re: Pass struct vfsmount to the inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 May 2007 15:41:09 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Tetsuo Handa <penguin-fsdevel@...ove.sakura.ne.jp>
Cc:	mrmacman_g4@....com, casey@...aufler-ca.com, jmorris@...ei.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: Pass struct vfsmount to the inode_create LSM hook

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/