Linux security non-modules and AppArmor

Linux security non-modules and AppArmor

Posted Jun 28, 2007 5:36 UTC (Thu) by arjan (subscriber, #36785)
In reply to: Linux security non-modules and AppArmor by jamesm
Parent article: Linux security non-modules and AppArmor

While I don't automatically want to agree that SELinux is the One True Thing, I do agree that LSM was a mistake in hindsight.

LSM was created because the security folks (many of whom were thinking of doing binary only proprietary things) couldn't agree. LInus decreed basically "I don't want to care so make it go away behind some interface". It made security stuff the 5th wheel of the kernel, with little visibility towards a real design... especially with most LSM stuff out of tree it's just hard to see how things really fit together.

I'm sad to see that many of the original companies and groups that are the cause of the LSM debacle just never came forward. The only one who half came forward is AppArmor, and it's funny to see how that sort of gets posted once a year, just in time for the Kernel Summit to have another "don't remove LSM because we're still here" argument...

Path based security has issues, and the one that Johnathan missed is the one where AppArmor has to reconstruct a full pathname by going backwards up the tree. That is just a major problem (and that is not the part that was seen at the last kernel summit as "ok"; only the "look at filenames" part was).

Anyway today we have a set of random hooks that have relatively unclear semantics, of which all but one user are out of tree so we can't do a sweep to even check if they are the right interface.... and the hooks also add a performance cost due to the indirect function pointer calls. At least the proposed path is step 1 to getting rid of the indirect calls and just having a "CONFIG_SELINUX_ONLY" option which turns the calls into direct calls.... killing the not insignificant function pointer call overhead.

---

(Log in to post comments)