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."
SElinux alone is an utter pain in the ass to work with, hence many Linux admins simply switch it off.
Extensions such as AppArmour (formerly known as SubDomain), are what people should be embracing in order to make practical use of this excellent technology. Whilst using the same kernel hooks, AppArmour allows you to "snapshot" an application's activity and build a ruleset which can then be applied to the process. Much easier than titting around with SElinux policies forever and a day...
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.
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.
I like to call it GNU/X11/Apache/Linux/TeX/Perl/Python/FreeCiv . FreeCiv is clearly at the core of it all.
The state you are in while your HEAD is detached... - wait, what?
Use SELinux commands like "restorecon" and "chcon" to fix SELinux context issues. Also, there is a GUI tool called "system-config-selinux" if you find that kind of stuff easier. If all else fails, use "setenforce" to put SELinux into WARN mode and look at the logs for clues about what is wrong.
The definitions used by the article for discretionary, mandatory and role-based access control are a bit confused. They mix up the type of control with mechanisms commonly used to implement them. To be fair, there are no standard definitions of them - or at least, there's more than one "standard" definition. However, having just completed a dissertation in which I attempted to define those things, allow me to offer them here.
Discretionary - a user has discretion to decide who has access to what. A common form of discretionary control is access control lists (ACLs), but capabilities are also discretionary. A big problem with discretionary control is the amount of work the user has to do to grant and revoke permissions to everything. This often leads to systems configured with too much permission - the opposite of principle of least privilege.
Mandatory - the system mandates who has access to what by enforcing a policy (a user may set the policy, but can't grant access outside of that policy). Mandatory systems can require less work to administer day-to-day, as authorisation has been automated. But its often a lot of work to set good policies and are obviously less capable of dealing with things that fall outside of normal working practices. Common forms of mandatory control include label based systems like Bell-LaPadula or Biba (e.g. Top Secret: nuclear;projectX) and protection rings in CPUs.
Role-based (RBAC)- the permissions of a user are taken from their role or roles. Lots of people ask why this isn't the same as using groups and access control lists. You can implement bits of RBAC using groups and ACLs, but full RBAC is more abstract than this, and explicitly allows for greater control - like separation of duties. The current "standard" is the NIST RBAC definition http://csrc.nist.gov/groups/SNS/rbac/)
Note that RBAC can be mandatory or discretionary - it doesn't say how the permissions are allocated to the roles, just how the user gets those permissions through the roles.
But WHAT if the company who made the oscilloscope also had secret deals with the NSA???
Yeah, that must be why TrustedBSD is copying SELinux (just like opensolaris)...
People claims SELinux is difficult, but they often don't understand how insanely powerful it is....
Yes, but they're usually just bit parts.
http://www.rootstrikers.org/
the "NSA" is not developing "your" OS. the NSA is (indirectly) verifying via (indirect) sponsorship and advocation that an (independent) university-developed scientific security model (FLASK) is (independently) implemented by a company and then (independently) maintained by (independent) people such as stephen smalley.
look at the web site. it say "POSIX not good enough for proper security. therefore we make it better so that civil services, and other environments where security matters, have someone to go to to ask 'is this secure to level XYZ?' and get a certification"
the bottom line is: be damn grateful for their involvement because it beefs up linux and allows it to be recommended for deployment in places where it would otherwise be hopelessly outclassed. remember: selinux allows linux to be "certified" as "secure", and mathematically provable as "secure". those certifications are absolutely vital for deployment in certain kinds of environments.
so be glad that linux is getting a leg-up, thanks to the NSA.
"they often don't understand how insanely powerful it is...."
:) from scratch, selinux takes about 6 to 8 weeks to understand and program "policies". that means that anyone with the skill to program it is onto a goldmine, especially in the kinds of defense and civil contracts where selinux is "required".
... absolutely insanely powerful, just as you say.
... i'm belabouring the point but you get the picture i'm sure. oh. and of course, you could even define that a particular ssh subsystem (sftp) be allowed from a particular range of IP addresses and ssh "shell" access only allowed from another range.
mwahahahah. yeah. nor how much money can be made from being able to program it and set up selinux policies that make normal people's brains bleed
i did a contract for a veeery unusual selinux deployment, involving file transfers from a high security environment to a low security one and vice-versa (secure-ftp). the requirement was that files in "incoming" should be creatable-and-writeable from one side, and from the other side they should be "readable-and-deletable" on the other.
the requirement was nothing to do with UNIX, it was implementing guidelines laid out in a policy document on security and was government-mandated for the type of environment (i wasn't told what that was but it was probably banking).
when my friend analysed the requirements, he did a simple map of POSIX permissions onto the requirements. POSIX merges "write" with "delete". automatically and immediately, pure POSIX permissions made it absolutely impossible to fulfil the requirements. he looked at extended ACLs: that didn't help, either.
on investigation of SElinux permissions, with extended separate permissions on directories as well as files, it was abundantly clear that SElinux fitted the requirements perfectly.
in SElinux, every single OS primitive has its own ACL permission, so there are about twenty five ACLs for files and a further separate and distinct twenty five or so ACLs for subdirectories. thirty or more for sockets. network addresses can be represented in ACLs. it's just
you could, if you were prepared to drive yourself up the wall, implement a per-user firewall for ssh. not using ssh configs but using selinux policy files! you could define the set of IP addresses which become relevant for a particular user context, which gets activated when the user logs in because PAM helps define the user's role, and then the combination of the user's role and the fact that the ssh "context" is entered, then network access is granted or denied because...
it is truly truly absolutely amazing.
But what if YOU have a secret deal with the NSA?
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...