Slashdot Log In
How the NSA Took Linux To the Next Level
Posted by
Soulskill
on Sun May 11, 2008 11:08 AM
from the not-by-beating-the-end-boss-of-the-previous-level dept.
from the not-by-beating-the-end-boss-of-the-previous-level dept.
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."
Related Stories
[+]
New Release Of NSA SELinux 210 comments
rstewart writes: "The NSA has released a new version of SELinux for public consumption. It is based on the 2.4.9 kernel and the utilities patches are known to work on Redhat 7.1. More information and the source can be found at the NSA SeLinux site." You can read the what's new for more information.
[+]
News: SELinux by Example 77 comments
Ravi writes "SELinux is a project started and actively maintained by the U.S Department of Defense to provide a Mandatory Access Controls mechanism in Linux. It had been a long standing grouse of Linux power users and system administrators over its lack of fine grained access control over various running processes as well as files in Linux. While Solaris touts its famous RBAC and Microsoft Windows has its own way of providing finer rights to its resources, Linux had to put up with the simple but crude user rights known in tech speak as discretionary access control to control user access of files. With SELinux project making great strides and now being bundled with many major Linux distributions, it is possible to effectively lock down a Linux system through judicious use of SELinux policies. SELinux implements a more flexible form of MAC called type enforcement and an optional form of multilevel security." Read the rest of Ravi's review.
Submission: How the NSA took Linux to the next level by Anonymous Coward
[+]
Ask Slashdot: Just How Effective is System Hardening? 154 comments
SkiifGeek, pointing to our recent coverage of what the NSA went through to create SELINUX, wants to know just how effective system hardening is at preventing successful attack, and writes "When Jay Beale presented at DefCon 14, he quoted statistics (PDF link) that Bastille protected against every major threat targeting Red Hat 6, before the threats were known. With simple techniques available for the everyday user which can start them on the path towards system hardening, just how effective have you found system and network hardening to be? The NSA does have some excellent guides to help harden not only your OS but also your browser and network equipment."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
All very good, but... (Score:4, Informative)
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...
Re:All very good, but... (Score:5, Informative)
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?
Parent
Re: (Score:2, Insightful)
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?
Yeah, yeah, yeah and it took years to calculate by hand before computers and months to travel any distance before airplanes. So what's your point?
SELinux is a pain in the ass. Your comparison is meaningless.
Re: (Score:3, Funny)
Re:All very good, but... (Score:4, Funny)
Parent
Re:All very good, but... (Score:4, Funny)
Well, you can get the same experience now, thanks to Symantec Antivirus. Well, except for the whole actual security part.
Parent
Re: (Score:3, Informative)
http://lists.opensuse.org/opensuse-bugs/2007-09/msg02994.html [opensuse.org]
https://bugs.launchpad.net/ubuntu/+bug/156693 [launchpad.net]
Re:All very good, but... (Score:5, Informative)
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...
Parent
Re:All very good, but... (Score:5, Interesting)
Fine by me.
Means that when it becomes mainstream, anyone who is familiar with how to configure and use it will be in high demand.
Parent
Re:All very good, but... (Score:5, Insightful)
If no one's using it, how will it become mainstream?
Parent
Re: (Score:3, Interesting)
If no one's using it, how will it become mainstream?
Quite simple really; Government mandate. Some agency will mandate it or make it part of some policy. From there it will spread into private sector via companies that do business with said agency. The Agency I work for is already doing just such a thing for new projects. Any company that is running Linux by contract has to secure their system through multiple methods; including SELinux.
Re:All very good, but... (Score:5, Informative)
A toolkit that allows for easy integration of new applications into SELinux and adaptations of already defined applikations would be useful. There are some around, but none are really good. The best would be if SELinux could allow for a "learning" mode for a single application in addition to the modes it has. Something like the Zonealarm firewall that is a bit noisy in the beginning, but as soon as it has learned what's permitted it goes silent. This will of course require a user-space application listening to the SELinux events. So a mode that allows SELinux to be permissive for a single application while strict for the rest of the system would be a nice thing.
One common problem that I have experienced is that databases like MySQL are defined in SELinux, but it's very common that the data storage is going to be relocated in a production environment. This is a cumbersome process that costs a lot of work and pain.
Another problem is the issue of semantics involved. It's not always clear and takes a lot of time to get familiar with.
And still - SELinux is a "static" security measure, which only controls the permitted access between application and resource. It doesn't consider any frequency or volume. For example - a mail program may do a limited number of connections to port 25 per second, which is a normal situation, but if a higher frequency occurs that means that there may be a problem that has to be checked. OK - It's not easy to be intelligent about things like this, but system behavior pattern is a critical point in security too.
So from a view of security SELinux is still only a step on the way, the threats of tomorrow has to be predicted and handled. This means that SELinux has to be a lot easier to work with for the average person to allow it to become a wide-spread security base.
Parent
Re:All very good, but... (Score:4, Informative)
Read up on "seaudit" and creating custom profiles.
(I still think the process could be a bit more human-friendly, but the tools do exist.)
For example - a mail program may do a limited number of connections to port 25 per second, which is a normal situation, but if a higher frequency occurs that means that there may be a problem that has to be checked. OK - It's not easy to be intelligent about things like this, but system behavior pattern is a critical point in security too.
Things like that are better handled in IPTABLES, or in the application itself. Those do not fall under the purview of SELinux which is about controlling access to the resource (not rate limiting or rationing out a resource).
Parent
Re:All very good, but... (Score:5, Insightful)
[ 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).
Parent
Re:All very good, but... (Score:5, Interesting)
None of that is the problem. The problem is in the WAY the access is specified by slicing and dicing the namespace to assign a security context to each object.
If I write an app that needs to access JUST ONE file in /etc and other apps already access it and a few more under a common context, I have two choices. I can allow my new app carte blanche on /etc (bad) or modify the policy of the other apps that may access the file to grant them the new context. Lather, rinse, and repeat until you've made a hash of the policy source (and the admin rips out his last chunk of hair).
Then, now that you've hacked away and sliced and diced enough to grant everything just what it needs and then you do yum update. I swear, you can actually HEAR satan laughing maniacally below as you have to either abort the security update (and be insecure), turn off MAC (and be insecure) or accept that half your system will be broken now (I suppose an app that won't even run IS secure, but now the ADMIN feels insecure).
what's needed is a policy.d directory. Each app is allowed to drop one file there that will be evaluated in isolation from whatever else is there to grant that particular app what it needs without having to understand the rest of the policy (perhaps modified locally anyway). The directory is there, but there's more than one and the files there have to understand the others and the global policy to avoid problems (like preventing the policy from compiling at all).
Most places simply do not wish to pay for the amount of admin time required to make all of that work. In many cases, they're well justified in that, the data on the systems just isn't worth that much.
When it is used, a common pattern is to run the app and then mindlessly add permisssions for whatever was denied until it finally works. The natural result is an overly permissive policy. All the disadvantages to using AppArmour automation plus granting entirely unnecessary access to any files related to the files needed.
My post sounds almost entirely negative, but that would be unfair. In the environment SELinux was developed for, where leaked information can be a real disaster, it makes perfect sense to invest the administrative effort that is required. For the rest of us, it got the kernel code moving in the right direction for MAC and MLS. That makes follow on schemes better suited to the rest of us more likely to happen.
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
No they can't. They can contract with a contractor to develop a piece of code, but the government cannot develop something and then give it to a corporation. If government employees are building it, it's public domain. That's the nature of US law.
Your statement is fallacious because the co
Re:All very good, but... (Score:5, Interesting)
Anyone out there who's used both grsec and SELinux + AppArmour want to favor us with a comparison?
Parent
Re:All very good, but... (Score:5, Informative)
audit2allow -a -m local
checkmodule -M -m -o local.m
semodule_package -o local.pp -m local.mod
semodule -i
sequence of commands plus togglesebool has so far accomplished everything I have ever needed. I don't run any hand-written custom policy. And we have web servers, dns, mysql, web dev, and all kinds of other stuff.
It sure is easier than setting up a bunch of iptables commands although I see it as analogous. I rarely hear people talk about what a pain iptables is (and it surely is a pain). I think learning SE Linux was even easier.
I really look forward to more policy being applied to the desktop applications. That work is already well underway thanks to Dan Walsh over at RedHat who has already made a lot of progress in this area:
http://danwalsh.livejournal.com/15700.html [livejournal.com]
http://danwalsh.livejournal.com/18578.html [livejournal.com]
http://danwalsh.livejournal.com/13376.html [livejournal.com]
It is work like this that leads me to believe that Linux is not nearly so likely to become like Windows should it ever achieve a critical mass of desktop users. Security problems on the massive scale of some other operating systems are not inevitable. That is nice to know.
Also, I will be doing a presentation on SE Linux at the Kernel Panic Linux Users Group:
http://www.kernel-panic.org/meetings/general/08-07-10-general-meeting [kernel-panic.org]
on July 10th, 2008. If you are in San Diego please stop by. It's a fun crowd and the after-meeting meeting at Denny's is always lively.
Parent
wrong (Score:3, Informative)
No it doesn't. SELinux adds both MAC and RBAC to the Linux kernel.
Re:wrong (Score:4, Funny)
Parent
Re: (Score:3, Insightful)
Of course including the Debian people, who made one of the greatest distros so far?
(NOT the greatest, but certainly one of the greatest)
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
I can't deny that I normally call the combination "Linux" myself, but I don't understand why some people are actively hostile to the concept of calling it "GNU/Linux" instead.
Re: (Score:3, Funny)
I prefer to say it more delicately, like "Everyone without a stick up his ass just calls the OS 'Linux'".
I realize that his is also divisive since it could be "stick up her ass", but I hate to make the facts come across as so wordy when you have to say "his or her ass".
Released? Please, recapture it! (Score:2, Informative)
Re:Released? Please, recapture it! (Score:4, Insightful)
Parent
Roles vs Groups? (Score:2)
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.
So a role is a group with permissions applied? WTF is the point of a group with no permissions applied?
Now I understand you can have different kinds of groups: email/distro, file access, memory access, execute, etc. But even if you use one group to give all of these, that doesn't really make it different that a group with permissions.
Is it all PHB/Marketing BS or am I missing something?
Learn how to use SELinux without disabling it... (Score:5, Informative)
Interesting article, but confused definitions (Score:5, Informative)
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/ [nist.gov])
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.
Re: (Score:2)
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.
Couldn't you accomplish separation of duties with groups (by using different groups for different duties) and/or setting up permissions in a less sweeping way in sudoers (not just always using "fubar ALL=(ALL) ALL")? I freely admit I know just enough to be dangerous; but sometimes I wonder if the problem is really just the way user/group permissions have traditionally been used in Linux/Unix.
Re: (Score:2)
Re:Security vs Functionality tradeoff (Score:5, Informative)
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.
Parent
Re: (Score:2)
Re:Do you really want NSA developing your OS? (Score:5, Insightful)
Parent
Re: (Score:2)
Re: (Score:2)
Sorry, but I'm paranoid. What if you're a NSA agent? So I think you're lying me - my CPUs are safe.
Re:Do you really want NSA developing your OS? (Score:5, Funny)
Parent
Re:Do you really want NSA developing your OS? (Score:5, Funny)
But what if YOU have a secret deal with the NSA?
Parent
Re: (Score:2, Insightful)
frankly i think it's wise to not trust the nsa even if you can see the code, because frankly it's just plain misplaced f
Re:Do you really want NSA developing your OS? (Score:5, Insightful)
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...
Parent
Re: (Score:3, Informative)
I've read that code, all of it. There are no back doors to be found there. It's all well structured and very clear. Various access functions in the kernel call into SELinux functions and get a simple Boolean result OK or not OK.
The VFS contains bits to implement the security.* xattrs.
Re: (Score:3, Funny)
Re: (Score:2)
If it keeps them off my phone line, then I'm all for it!
I hear voices, but they *usually* belong to people.
Re: (Score:3, Insightful)
And aside from that, lets see, they have arguably several hundred to thousands of the best crypto and security people working for them so yeah lets completely ignore what they have to say in favor of some nebulous conspiracy.
Think about this: could such a conspiracy exist with that many people being informed of it? All it takes is one
Re:Do you really want NSA developing your OS? (Score:5, Interesting)
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.
Parent
Re:TrustedBSD (Score:5, Informative)
People claims SELinux is difficult, but they often don't understand how insanely powerful it is....
Parent
Re:TrustedBSD (Score:5, Informative)
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.
Parent
Re: (Score:2, Informative)
Re:Roles (Score:5, Funny)
Parent