| |||||||||||||
Kernel Summit 2006: SecurityKernel Summit 2006: SecurityPosted Jul 24, 2006 17:01 UTC (Mon) by Method (guest, #26150)In reply to: Kernel Summit 2006: Security by crispin Parent article: Kernel Summit 2006: Security
I'm actually not going to go through this in LWN comments, its very unproductive. However, you had one entirely false statement in your comment:
That is absolutely incorrect, as I pointed out in my blog entry and in previous email discussions a single path (eg., /etc/shadow) can refer to "/etc/shadow" in any namespace (chroots or private namespaces).
The great thing about this is that, for example, your bind "policy" gives access to /.* (that means any file on the filesystem), because it is assumed that bind is chrooted.
It doesn't take a genius to figure out that this is incredibly bad if bind fails to chroot, or if someone changes its configuration, etc.
This shows very clearly that apparmor is essentially a "fail open" security mechanism which is the worst possible thing from a security standpoint (particularly since the user won't even find out).
The alternative labeled security systems fail closed so if bind couldn't chroot it doesn't matter, it can't access anything on the system.
Anyway, thats it for my responses here, there are far more productive ways of relaying this information than through comments. ciao.
(Log in to post comments)
Kernel Summit 2006: Security Posted Jul 24, 2006 20:12 UTC (Mon) by nix (subscriber, #2304) [Link] It doesn't take a genius to grasp that AppArmor counters this by banning namespace changes (other than chroot(), which can be handled) for covered applications. Yes, this means no fancy shared subtree hacks can be carried out by apps that are *actually covered*, but since shared subtree hacks are often done by login PAM modules, and that's not going to be stuff you're going to protect with AppArmor...
You continue to complain that AppArmor is useless because it doesn't try to protect absolutely everything all of the time, even though *this was a design goal*.
AppArmor and chroot Posted Jul 24, 2006 23:51 UTC (Mon) by sweikart (guest, #4276) [Link] > The great thing about this is that, for example, your bind> "policy" gives access to /.* (that means any file on the > filesystem), because it is assumed that bind is chrooted. > ... This shows very clearly that apparmor is essentially a > "fail open" security mechanism
If 'bind' is configured to chroot to e.g. /chroot/bind, then it seems like a mistake to have bind's AppArmor policy specify pathname-access with /.*; it seems like the policy should specify "real" path names, i.e. /chroot/bind/* . This way, AppArmor apps would "fail closed" rather then "fail open". [This methodology might also work with namespace changes.]
-scott
Kernel Summit 2006: Security Posted Jul 25, 2006 21:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] and the reply to this by AppArmor was that they are enhancing AA to look at the path to the file looking through the namespace mappings.
so you wouldn't have a policy that granted /.* to bind, you would have a policy that granted /chroot/.* to bind. thus if bind fails the chroot it would have no access to anything that it wouldn't have access to if the chroot suceeded (and it would then fail miserably since nothing was where it expected)
yes this was a real issue, but it's also a straightforward one to resolve.
|
|||||||||||||