Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks | From | Stephen Smalley <> | Date | Wed, 19 Apr 2006 08:40:36 -0400 |
| |
On Tue, 2006-04-18 at 13:57 -0700, Crispin Cowan wrote: > SELinux has NSA legacy, and that is reflected in their inode design: it > is much better at protecting secrecy, which is the NSA's historic > mission. AppArmor has legacy in intrusion prevention, and so its primary > design goal was to prevent compromised programs from compromising the > host. Name-based access control is better at that, because it lets you > directly control which programs can change the contents of path names > that have critical semantic meaning in UNIX/Linux, such as /etc/shadow, > /etc/hosts.allow, /srv/www/htdocs/index.html and so forth.
This is bunk, pure and simple. The core security model of SELinux is Type Enforcement, and Type Enforcement was originally used for integrity, as a mechanism for complementing and filling in the gaps left by the MLS (secrecy/confidentiality) model. Type Enforcement can be used for confidentiality as well, as it is just a simplification of the Lampson access matrix, but its original goals were integrity oriented. Name-based access control is _not_ better for integrity. You don't want trusted program FOO (e.g. /bin/su) to accept data from an untrustworthy file that happens to be named /etc/shadow in your namespace, so you want your integrity controls to be governed by the real security attributes of the real object, not just its name. The only argument I've seen regarding "names are better for integrity" is that it is easier to preserve the association when the object is re-created at that location. But that association may be fallacious - if an untrustworthy process re-created /etc/shadow, I don't want it to retain an association with high integrity data.
-- Stephen Smalley National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |