Forgot your password?
typodupeerror
Security Operating Systems Software Government Linux News

How the NSA Took Linux To the Next Level 172

Posted by Soulskill
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."
This discussion has been archived. No new comments can be posted.

How the NSA Took Linux To the Next Level

Comments Filter:
  • by Shuntros (1059306) on Sunday May 11, 2008 @12:14PM (#23369580)
    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...
  • wrong (Score:3, Informative)

    by larry bagina (561269) on Sunday May 11, 2008 @12:19PM (#23369624) Journal
    SELinux adds both MAC and RBAC to the GNU/Linux operating system.

    No it doesn't. SELinux adds both MAC and RBAC to the Linux kernel.

  • by Monty Worm (7264) on Sunday May 11, 2008 @12:26PM (#23369666) Journal
    This is timely, if nothing else. I've spent the last working day wrestling with what turned out to be SELinux, while trying to write a postfix filter. The way these work is postfix gives emails as command line options and STDIO, and the software (usually) connects to SMTP on an alternative port to move the email on. Except with SELinux running (which is installed by default in some distros), it fails. Silently. Please, take it away!
  • by FurtiveGlancer (1274746) <(moc.loa) (ta) (yuGhceTcoHdA)> on Sunday May 11, 2008 @12:37PM (#23369740) Journal

    utter pain in the ass to work with....

    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?

  • by garett_spencley (193892) on Sunday May 11, 2008 @12:38PM (#23369748) Journal
    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.
  • by TheLink (130905) on Sunday May 11, 2008 @12:50PM (#23369824) Journal
    Yeah and we need some thing like "template sandboxes" on top of something like AppArmor.

    http://lists.opensuse.org/opensuse-bugs/2007-09/msg02994.html [opensuse.org]

    https://bugs.launchpad.net/ubuntu/+bug/156693 [launchpad.net]
  • by Ang31us (1132361) on Sunday May 11, 2008 @01:06PM (#23369922) Homepage
    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.
  • by mattpalmer1086 (707360) on Sunday May 11, 2008 @01:10PM (#23369936)
    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/ [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.
  • by Znork (31774) on Sunday May 11, 2008 @01:17PM (#23369970)
    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...
  • by Z00L00K (682162) on Sunday May 11, 2008 @01:27PM (#23370020) Homepage
    The concept of SELinux is good, but it isn't very friendly for the system administrator and the developers.

    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.

  • Re:TrustedBSD (Score:5, Informative)

    by diegocgteleline.es (653730) on Sunday May 11, 2008 @01:41PM (#23370122)
    Yeah, that must be why TrustedBSD is copying SELinux [trustedbsd.org] (just like opensolaris [opensolaris.org])...

    People claims SELinux is difficult, but they often don't understand how insanely powerful it is....
  • by Darkness404 (1287218) on Sunday May 11, 2008 @02:09PM (#23370258)
    The code is open, anyone can review it. SELinux is open source, you can even edit the source code itself. Now had this been a proprietary product you would have no clue what is in the binary, but with Linux you can be assured that you can look it over. Compare that to Windows where you don't even know who is editing the source code. And really, how can you put in hidden code in the source code? You can't. Now granted, I hate SELinux for other reasons but it being developed by the NSA isn't one of them.
  • by Hal_Porter (817932) on Sunday May 11, 2008 @02:16PM (#23370306)
    Why do people say "you can read the code". Firstly, how many people who are actually skilled enough to read code critically have time to do that? And what's the chance out of the millions of lines of code in the kernel that they just happen to find the very few with bugs.

    And how many of those are looking to fix old bugs as opposed to add new features? Bugs can exist in code that lots of people look at for 25 years.

    http://it.slashdot.org/article.pl?sid=08/05/11/1339228 [slashdot.org]

    Most subtle bugs can't be seen by reading code anyway, and you can't find them in a debugger because they are so hard to reproduce. Instead you need to form hypothesis about what the mechanism is, test them and then try possible fixes. And then get lots of people to test those.

    Most interesting bugs only get understood/fixed when someone is affected by them. Having millions of people stare at the code to find one chance in a million is pointless. In fact it's worse than that since those people will be tempted to refactor working but ugly code intead of hunting for those hard to find bugs.

    The concept is totally naive, IMO. Only people who've never found a very subtle bug would believe it.
  • Re:TrustedBSD (Score:5, Informative)

    by lkcl (517947) <lkcl@lkcl.net> on Sunday May 11, 2008 @03:14PM (#23370666) Homepage
    "they often don't understand how insanely powerful it is...."

    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 :) 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".

    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 ... absolutely insanely powerful, just as you say.

    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... ... 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.

    it is truly truly absolutely amazing.

  • by Tracy Reed (3563) <treed@ultraviol[ ]org ['et.' in gap]> on Sunday May 11, 2008 @08:08PM (#23372816) Homepage
    I have been deployed around 30 CentOS 5 boxes over the last 6 months. I used to turn SE Linux off when it was expedient. Not anymore. I educated myself about how it works and a few basic commands. This:

    audit2allow -a -m local

    checkmodule -M -m -o local.m

    semodule_package -o local.pp -m local.mod

    semodule -i ./local.pp

    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.
  • by sjames (1099) on Sunday May 11, 2008 @09:27PM (#23373338) Homepage

    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.

  • by WuphonsReach (684551) on Monday May 12, 2008 @08:25AM (#23376494)
    The best would be if SELinux could allow for a "learning" mode for a single application in addition to the modes it has.

    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).

  • Re:wrong (Score:2, Informative)

    by larry bagina (561269) on Monday May 12, 2008 @05:17PM (#23384034) Journal
    early versions of Linux used minix user space applications.

Luck, that's when preparation and opportunity meet. -- P.E. Trudeau

Working...