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...
No it doesn't. SELinux adds both MAC and RBAC to the Linux kernel.
Do you even lift?
These aren't the 'roids you're looking for.
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!
... and today's pet project has
Microsloth is only very slowing coming around to the idea of user accounts and privilege isolation (badly implemented in MS-Windows-Vista) in spite of repeated warnings from the NIST and the longtime availability of NIST Registry patches. While MS might be suboptimizing for low early user-support calls, they are not entirely stupid and must have chosen low security defaults for some reasons.
Until these reasons for low security are thoroughly discussed and refuted, that model will persist. "Better safe than sorry" convinces only those already convinced. I say: Better neither than either.
I think RSBAC (linux kernel patch) covers that, and much more. http://www.rsbac.org/
Until we have a free government, I cannot see how anyone can trust software that comes from the NSA.
Hasn't NT had Roles for 15 years?
"The concept of a role differs from that of a traditional group in that a group represents one or more users."
/etc/group, it represents on or more users. So what are they trying to say with this sentence?
And so does a traditional group in
I would rather deal with the simple security that comes with Linux and already works well than to have to try to figure out a poorly implemented security system that emits an endless stream of crap into my log files and breaks something just about every time my distro updates it.
Simple and understandable makes for better security than complicated and unfathomable.
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?
No comprende? Let me type that a little slower for you...
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.
Unless you are married to Linux already for some reason, you'll want TrustedBSD. Built on top of/as extension to FreeBSD, it had a substantial head-start...
In Soviet Washington the swamp drains you.
Why is rsbac never mentioned on slashdot? It is, in my opinion, a better technology. At the least, it is a different approach, and worth mentioning. I use it daily, find it easier to administer than selinux, it is more portable, and does not need LSM. Check it out at http://www.rsbac.org/
http://www.nsa.gov/selinux/info/faq.cfm
I bet you run windows.
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.
Taxation is legalized theft, no more, no less.
you are an idiot
"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 sounds neat on a theoretical level, but how does it help me? Does my system have any programs which respond to socket requests but don't access the file system? Even my web server reads from my database, and writes to log files.
I suppose I could use it to lock down my echo service, but I don't recall seeing many security advisories about that.
Is there some real-world example that makes sense that you could explain to an idiot like me?
What's with people having so much faith in the security of open source software? Seriously, how many hundreds of thousands of lines makes up SELinux? Have you even reviewed 500 of those lines yourself? The vast size of it, makes it impossible for any one individual or even group of small individuals to KNOW for sure it is all perfectly safe. Now prove to me that some group expert coders that have actually reviewed every single god damn line of it and found nothing wrong with it, and maybe then I'll start trusting it.
Rough Analogy: It's all about logistics people. Just because there is a freedom of information act out there, doesn't mean every single government document has ever been reviewed, and it doesn't make the government trustworthy.
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
Well, if I shoot my foot with a gun, I get a hole in my foot. If I use SELinux, I end up with a pretty secure OS. These are different things.
Now, if you have information that may be able to give me a secure OS using a gun, or perhaps more interestingly a hole in my foot using SELinux, feel free to enlighten me :)
Oh, FWIW, paranoia is great up until the point it becomes easily confused with irrationality. Irrational paranoia is usually reserved for the domain of the mentally ill.
There is nothing interesting going on at my blog
How many people have looked through all the lines in a recipe and understand all the chemical reactions? Seriously, whats with people having faith in how somehow someone wouldn't slip in something that would be poisonous that the maintainers of the recipe wouldn't notice? Compare recipe to SELinux and you get the general picture.
And why would Debian, Red Hat, Ubuntu, and Fedora have it if it were malicious? Despite the fact that the US government could have made Red Hat put it in for Red Hat and Fedora, that still leaves Debian which is community (and is quite good about making sure its systems are secure) and Ubuntu which is based in the UK and is community much like Debian.
Sure, healthy suspicion is good, but really, its just as stupid as saying because not everyone knows what the chemical reactions are when you are cooking it suddenly leaves you open to poison yourself with it.
Taxation is legalized theft, no more, no less.
Wow, adding permissions to groups! What a concept! Welcome to the late 20th century Linux.
SELinux's security is rooted in Type Enforcement, which is similar to a mandatory RBAC but not built around user roles, but rather the roles of processes. For example, a mail filter may run as root to be able to write user mailboxes, but the various processes involved in it will not be able to, for example, read user documents (they will only be able to read files that are directly involved with the needs of mail delivery).
The idea is that even if there is vulnerability with the mailer, at worse the attacker could read/delete user mail (and not, for example, install trojans into applications or reconfigure the network).
This is orthogonal to any user based controls (i.e.,the mail filter may start out running as root or some mail daemon, and then later su to the user, but it will remain in the "mail filter" domain).
You're just not living in the real world.
One should expect the NSA to have placed several non-obvious trojans in SElinux code, as well as in other areas of the kernel not directly tied to security. This is part of what they do, to acquire access pathways into systems worldwide for when they're needed, and undoubtedly it's the part of their Linux work for which they get funding most easily.
After all, it would be totally unreal and naive to think that the NSA greeted the rise of Linux with total submission. "Oh dear, it's been so easy to place our access hooks into Windows with the assistance of Microsoft until now, but Linux is open source so we're totally defeated, you can take away half our funding now." Be real, that's not how the world works.
The overall security of Linux dropped when the security modules framework was added to support SElinux and AppArmor, because this is complex code that is inherently involved with privilege manipulation. You can bet your bottom dollar that there is a compromiseable pathway in that code, hidden as a side effect of some seemingly innocuous operation.
Without this, the NSA would not be doing the job expected of them, which is to undermine the rest of the world for the benefit of the USA. The rise of Linux represented a disastrous loss of control for the NSA. They would not have let that happen unchecked.
There is not a shred of evidence that SELinux is any more secure than other approaches to Linux security. In fact, in practice, it may well be less secure since it is so complex and hard to deploy: either people disable it entirely, or they configure it wrong and have a false sense of security.
To me, SELinux represents a lot of what is wrong with security today: people think that they can achieve security by just tacking a bunch of complicated software on top of existing systems, and people think they can get away with ignoring usability and users.
I may be wrong but I'm pretty sure 'system-config-selinux' is specific to Fedora (or at least Red Hat related distros). All the other system-config-* commands seem to be at least.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
To restate the OP more elegantly:
Which would you rather have?
A. Countless lines of obscure (but technically open source) code developed by the masters of deception who have unlimited resources at their disposal and who have a track record of intrusion where they have no business
B. Open source governance, where everyone can develop and read the law (and btw there is no NSA anymore because there is transparency in everything)
This is reality! How many Windows admins do you know that are thoroughly competent?
How many "Linux Admins" do you know that are aware of, and can competently command and control all aspects of one Linux system, let alone 5, 20, or 200?
"Security through complexity" didn't become cliche by accident..
And I am referring to server environments where you aren't constant adding removing programs. If you think SELinux is a pain in the ass to use for any software that comes packaged for the distro you're using, either there is a problem with the package itself, or there is some strange thing wrong. If we were talking about SELinux in FC2 I would agree, but at F8 , EL5 level, there is really not excuse. The devs even made a tool which tells you exactly how ti fix issues that cause alerts|blocks.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
You log in, you do your stuff. You need to bounce your network because of some guff.
/var/log directory or other people's TMP space. Normally requires root, well you can have a role that says "can edit disk owned by others under /var/log or /tmp" and you don't have to be root. You just need to have "edit disk ...." as part of your role.
So you run sudo.
You are still you, but your role includes "bouncing network to fix problems".
Or you may have to be able to clear out the
And you can't use the power of root otherwise required to, say, hose the system.
Why don't we just run the NSA by wiki?
I am sure everyone would go along with that.
Am I mistaken, or does this have nothing to do with Mandatory Access Control? I was under the impressions that MAC (as opposed to DAC) was based on how the policy is implemented. In MAC the policy is defined by the administrator, whereas in DAC, the policy is defined by the users. The example seems like a policy is not an access control method.
Perhaps the correct way to solve this misconception would be to find some better acronyms/names...
Here's a list of supported distributions (at least for that specific RPM). I first used it in RHEL 5 and CentOS is probably a good way to go if you want to get close to RHEL. Also, I forgot to mention that the "setsebool" command is also useful.
- that the NSA hasn't planted a backdoor somewhere in the code? Isn't that what they wanted in windows? I know it is OSS, but it is still a lot of code, and inspecting it all is a bit beyond me.
Now prove to me that some group expert coders that have actually reviewed every single god damn line of it and found nothing wrong with it, and maybe then I'll start trusting it.
This is totally missing the point. The point is that the NSA would know that there is a significant chance that someone somewhere *could* find any malicious code and expose it or use it against US companies/interests. The risk is far too high.
Without reading the article in any detail and researching things - this sounds a lot like what the .NET CAS (Code Access Security)features do, and have been doing so for around 6-7 years now.
:)
It is quite easy so configure a set of operations that I want an executable to be able to do, or not to do.
I suppose I will get flamed and modded down for mentioning this
Let me just remind people that NSA once published an improved version of the SHA encryption algorithm. Some time later, people have discovered a method of braking it really fast. What it meant in essence is that NSA was able to crack "safe" data with no sweat, while we thought their contribution was a friendly gesture. I'm not implying anything, I'm just saying: should it happen again, we should seriously consider revising all code contributed by them, and refusing their future contributions. We can always make the same thing based on their idea, and try and make it secure.