Rationale ========= Using some kind of [[!wikipedia Mandatory Access Control]], such as GrSecurity, AppArmor or SELinux, would make exploitation of security issues in bundled software harder. Possible solutions ================== AppArmor -------- See [[contribute/design/application_isolation]]. grsecurity ---------- [homepage](http://grsecurity.net/) grsecurity, along with more kernel hardening features, provides Role-Based Access Control. Some of its bonus features are slowly implemented upstream though (ASLR stack/heap protection, information leakage through the proc and sys filesystems, ways to disable module loading, etc). A feature that might be problematic is the "admin role" which is a superuser (more then root in grsec) that has the ability to modify/(des)activate grsecurity. How to implement this in a Tails environment, where passwords aren't that secret? Should users of Tails be able to login in that role, and if so, how could we provide a way to do so without lower grsec security by revealing worldwide this password? Users: - Hardened Gentoo offers a grsec-enabled kernel. RBAC policy? - Although Liberte Linux uses PaX (Address space modification protection) it does not include grsecurity RBAC feature. - Work to add a grsec kernel flavour to Debian seems to be stalled: [[!debbug 605090]]. - Ubuntu developers [used to actively work](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening) to upstream grsec features mainline, but this effort seems to have stalled, or rather moved to another employer along with Kees Cook. SELinux ------- Developed initially by big brother (NSA). It is pretty hard to write and maintain policies, but such policies exist and they can "mostly" be used by different Linux distributions. Poor support in Debian, improved in Squeeze, does not look like it's going to improve that much. - - - selinux policies are part of Squeeze - GNOME, policykit, etc. are supported by Debian-packaged policies, but who is actually using them to confirm they work well? Smack ----- The Smack MAC LSM is part of the Linux kernel ([homepage](http://schaufler-ca.com/), [[!wikipedia Simplified_Mandatory_Access_Control_Kernel]]). It does not seem to be used by any GNU/Linux distribution out there. TOMOYO Linux ------------ Some (MAC for files) of the TOMOYO Linux LSM ([homepage](http://tomoyo.sourceforge.jp/)) was mainlined in 2.6.30; more of it was merged in 2.6.34 and 2.6.36. It is compiled into Debian Squeeze's kernel. The out-of-tree patch has far more features, see the [comparison of versions](http://tomoyo.sourceforge.jp/comparison.html.en) for details. A "tomoyo learning daemon" is actually being developed by a third party : [tomld](http://log69.com/tomld_en.html), might be worst having a look and test it. For informations on the ongoing tests of this solution, see the [[tomoyo|Mandatory_Access_Control/tomoyo]] subpage. RSBAC ----- RSBAC is a Rule Set Based Access Control. It has a lot of other features. It's just a patch to the linux kernel, and probably won't be integrated upstream. Seems no distributions did integrate it or provide easy ways to do so. Ubuntu has a [package](http://packages.ubuntu.com/search?keywords=rsbac-admin) of the rsbac-admin utility. - - Resources ========= - - - [Comparing SELinux/AppArmor/GRSecurity](http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html) - [Another comparison from gentoo](http://www.gentoo-wiki.info/Access_Control_Comparison_Table) - [yet another comparison](http://elinux.org/Mandatory_Access_Control_Comparison) - [An exploit that was able to bypass SELinux and AppArmor protections](http://lwn.net/Articles/341773/) by the author of grsecurity, which was safe.