Systrace

Systrace

Posted Apr 20, 2006 19:21 UTC (Thu) by mheily (guest, #27123)
In reply to: Systrace by shahms
Parent article: Quotes of the week

For the record, I have never used AppArmor or looked at their FAQ; my assertions were based on reading the SELinux FAQ and asking myself 'Who built this, and why would anyone want something like this?'.

SELinux was a research project within the NSA. The defensive mission of the NSA is to "[protect] all classified and sensitive information that is stored or sent through U.S. government equipment". Therefore it is safe to assume that the rationale for SELinux was to enable MLS for sensitive government data; the only way to do MLS correctly on a single system image is to have MAC on all system objects.

When you look at the front page of the SELinux site, the second paragraph supports my hypothesis:

"End systems must be able to enforce the separation of information based on confidentiality and integrity requirements to provide system security. Operating system security mechanisms are the foundation for ensuring such separation. Unfortunately, existing mainstream operating systems lack the critical security feature required for enforcing separation: mandatory access control. As a consequence, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security."

So it seems that MAC is a means to achieve the end goal of MLS. To most non-government organizations, MLS is unnecessary, so the "pain" of architecting a complete security solution around MAC is not worth the "gain".

I'm not trying to say that SELinux will never become pratical and useful for the 'common admin'; over time, and given the enormous momentum behind it, I'm sure it will become the most successful and commonly deployed MAC system.

All I am saying is that right now we have pretty good cross-platform security mechanisms like chroot(2), privilege revocation, privilege separation, Sudo, and Systrace. Virtualization using Xen is another portable approach. You can also address buffer overflows using stack protection a la ProPolice or GCC's upcoming Mudflaps-based stack protector. Combine all these automated mechanisms with good coding practices, such as using Safestr or a similar string library instead of strncpy(3), and peer review of open and freely available source code, and you get a "layering effect" where flaws in one layer are caught in another layer.

SELinux is a comprehensive, radical approach to system security that has destabilizing effects on the entire software ecosystem. I prefer simpler incremental improvements to security, such as Systrace.

---

(Log in to post comments)