Slashdot Mirror
How the NSA Took Linux To the Next Level
An anonymous reader brings us IBM Developerworks' recent analysis of how the NSA built SELinux to withstand attacks. The article shows us some of the relevant kernel architecture and compares SELinux to a few other approaches. We've discussed SELinux in the past. Quoting:
"If you have a program that responds to socket requests but doesn't need to access the file system, then that program should be able to listen on a given socket but not have access to the file system. That way, if the program is exploited in some way, its access is explicitly minimized. This type of control is called mandatory access control (MAC). Another approach to controlling access is role-based access control (RBAC). In RBAC, permissions are provided based on roles that are granted by the security system. The concept of a role differs from that of a traditional group in that a group represents one or more users. A role can represent multiple users, but it also represents the permissions that a set of users can perform. SELinux adds both MAC and RBAC to the GNU/Linux operating system."
Long ago, in the days when MLS was just the holy grail, Harris Corporation created the first A1 rated Multi-Level Secure computer system. I can't recall the name given to it, BlackHawk or something overblown like that. It was secure, but utterly unusable. According to some early testers I knew, it took more than 10 minutes just to log on. The command line took, on average, 5 minutes to respond to the simplest command. There were no policy templates, so all permissions and access lists had to be entered manually.
SELinux doesn't look quite so bad in that light, now does it?
Invenio via vel creo
I don't see any mention SEL will run Firefox.
SEL doesn't "run" anything. It's basically access control lists implemented for the Linux kernel. So rather than using only the traditional unix-based filesystem permissions you can finely control what individual processes, groups and users can do in ways not possible with unix filesystem permissions alone.
It's explained not just in TFA but the summary:
"If you have a program that responds to socket requests but doesn't need to access the file system, then that program should be able to listen on a given socket but not have access to the file system. That way, if the program is exploited in some way, its access is explicitly minimized. This type of control is called mandatory access control (MAC). Another approach to controlling access is role-based access control (RBAC). In RBAC, permissions are provided based on roles that are granted by the security system. The concept of a role differs from that of a traditional group in that a group represents one or more users. A role can represent multiple users, but it also represents the permissions that a set of users can perform. SELinux adds both MAC and RBAC to the GNU/Linux operating system."
You can think of SEL as being an "add-on" to the Linux kernel. I realize that the name can be confusing since it kind of implies that it may be a completely different "Linux system" all together. It's really just an implementation of access control lists for Linux and various Linux distrubitions (such as Redhat) ship with it. It doesn't alter what the system can and can't run. It simply provides a tool for the administrator to further control and lock down the system in ways that are otherwise not possible with vanilla kernel.
SElinux alone is an utter pain in the ass to work with, hence many Linux admins simply switch it off.
I used to think so, but IMO, around FC7, F8 and RHEL 5 (ie, last year) the tipping point was reached. setroubleshoot and the tools around it are verbose to the point of telling you what to type so it's neither a problem noticing that there is an selinux denial nor any problem finding out what to do about it anymore.
Many integration problems (applications and libraries doing funky stuff they plain shouldn't be doing, something not unique to selinux) have also been fixed at the appropriate places, leading to far fewer failures.
Switching to MAC security has historically always been a serious pain in the ass (to the point where admins may have been better off implementing security by lack of mains power), but considering how painless it's gotten now I'd say whining about SElinux today says more about the admin than the software...