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."
Uh...you can read the code. People has read the code and there's nothing "hidden" on it. People who thinks that SELinux allows the NSA to enter your computer are just clueless.
Why not just fix the silent failure? I don't understand this mentality of "There's a bug in the system! Scrap the whole thing!"
if you believe that selinux is "an utter pain in the ass" then you have misunderstood what selinux is for. selinux is specifically designed to be able to PROVE that an application is secure, using formal mathematical analysis (of the policy files).
... even ... remotely worth considering.
[ the principle on which selinux works is that when you change "security context", it doesn't matter a damn if you were "god" before, you're now starting from scratch with zero permissions in the new context unless otherwise specified. this is best illustrated with an example of when you go into a military environment, they take your ID badge away from you and issue you with a temporary one that is only relevant inside that building. you can't even leave the building without that temporary badge, and it's been coded to only let you go to the toilet and into the rooms that are associated with your specific purpose for being in that building. and of course, if you forget to get your permanent ID back once you _do_ leave, you'll find it very difficult to get out the country! ]
one of the "rules" that GCHQ and the NSA follow is that it is perfectly acceptable for something to be "insecure" as long as you KNOW that it's insecure: you can then provide a workaround or a fix to ensure that the security vulnerability is never exploited.
the one thing that you absolutely absolutely must not ever have is a situation where you don't KNOW whether something is "secure" or "insecure".
so if AppArmour has wonderful automated rulesets that are impossible to analyse...
the thing about selinux is that policies require that you understand the source code and what the application is doing. for example, one of the guidelines is that applications should use exec rather than fork, because that provides total privilege separation, obviously, between tasks. fork() does not provide such a complete level of privilege separation, and so up until quite recently there was absolutely no way in selinux to even step into a separate security context on a fork() - it just... wasn't
however, it turns out that there were some specific instances why stepping into a different security context on fork() is actually useful (such as in samba) and so it was added in. due to the circumstances under which this could be thoroughly abused, it was decided that it should be provided only via an explict selinux function call (usually, you can just provide an selinux policy statement without any code modifications).
If no one's using it, how will it become mainstream?
You're forgetting that Linux development is distributed across the world. Maybe the NSA might conceivably be able to "silence" developers within the USA. But what hold exactly would the NSA have over developers in Europe and Asia? Even if you suppose that the USA's close allies such as Britain and Canada might be persuaded to join in some conspiracy, what would other countries have to gain? You would have to propose a global conspiracy, with governments the world over uniting to, um, stop themselves from finding out about the backdoors that America was using to spy on them? Sorry, but this is the most half-baked conspiracy theory I've ever heard.Leaving aside the clear paranoia that is causing you to characterise the NSA as "malicious", they would have to be not only malicious but downright stupid to put backdoors into open-source code.
For example, the Chinese government uses Linux themselves. It would be foolhardy in the extreme for NSA to assume that they will not have their best security experts scouring the code for backdoors. If they found one, they could use it themselves -- or they could expose it, seriously embarrassing the United States. Not exactly the kind of thing that's likely to result in NSA funding being maintained at its present high level...