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
I think RSBAC (linux kernel patch) covers that, and much more. http://www.rsbac.org/
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.
Here you go... and in your size too! Yep, a nice tinfoil hat, provided by the NSA no less!
Seven Days with Ubuntu Unity
Hasn't NT had Roles for 15 years?
If it keeps them off my phone line, then I'm all for it!
I hear voices, but they *usually* belong to people.
Invenio via vel creo
Put your nearly insane conspiracy theories to rest on this one, thats one of the reasons we have open source: to keep things like Microsoft's backdoors from being slipped in.
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 person to anonymusly leak stuff to the papers or internet. I mean really, the secret money tracing stuff they were doing got splashed on the front pages of the NYTimes, and the previous administration couldn't even keep a presidential blowjob a secret.
But the bottom line is: It is OPEN SOURCE (and even GPL'd!). Read the code. They cannot hide a backdoor from the kernel group when those programmers and all the patchers, testers, and users have all the source.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo! http://goo.gl/J9bkO
They might be able to do that anyway. Who knows if they hadn't had secret deals with Intel, AMD, or whomever? You probably cannot review the source code of your CPU.
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.
They might be able to do that anyway. Who knows if they hadn't had secret deals with Intel, AMD, or whomever? You probably cannot review the source code of your CPU.
Sorry, but I'm paranoid. What if you're a NSA agent? So I think you're lying me - my CPUs are safe.
I'll bet money that 99% of the people who have access to the code would have no clue what it does. that only leaves those who are familiar with it and those that know the language it is written in but are not familiar with the specific code. the former would easily be silenced, the later can be dismissed as kooks and better yet other people will do it to them as well due to herd mentality.
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 faith that a simple philosophy like oss can universally protect you from such malicious intent, Especially considering the history and track record of such a agency.
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....
So as long as the code doesn't execute the PWN instruction, we're safe.
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.
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
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
So some people don't understand the code very well. Thats why the 1% of people look for malicious changes and fix them. How many open-source projects have malware in them compared to all the Windows Freeware/Shareware/Adware that has it in them? Its like saying just because a recipe isn't verified by a chemist it must be designed to either A) Poison you or B) affect your mind to buy less of a competitors product. Source code can be compared to a recipe, and how many people who cook really know the science behind why they add in everything to bake a cake? I'm sure very few but how many die from incorrect recipes that were changed? I'm sure very very very few ton none.
Taxation is legalized theft, no more, no less.
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.
You web server only needs to listen on specific ports, and only needs to read from and write to specific paths. SELinux can enforce those limitations.
You know that too much paranoia is bad? (: your thoughts make up your reality.
Then your world has been virtualised out from under you, Matrix style.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
You can read a EULA too, but how often do people do that? Now lets think here... How many Linux sysadmins are proficient in C (i.e. have at least the knowledge contained in K&R)? Of those, how many have enough knowledge to understand kernel code? Of those, how many have the spare time to do so? And of those, how many will bother? And of those, how many will build the OS from source to ensure that the binaries aren't compromised? Just because something is open source doesn't necessarily mean it's safe. I'm not saying I think there is or is not a devious plot here.. But I am saying that you shouldn't assume that open source code cannot be malicious.
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?
People claims SELinux is difficult, but they often don't understand how insanely powerful it is....
No, it isn't powerful. "Powerful" doesn't just mean being able to get a lot done, it means getting a lot done with little time or effort.
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)
If you are going to take competency of the admin into account when analyzing how secure a system can be, then you are pretty much already screwed.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
This is not quite correct. With SELinux, the vendor can define precise roles for all the system daemons for instance. This definitely improves security because even if a buffer overflow is discovered in one of them, if they are barred from interacting with the filesystem for instance, the security breach cannot be exploited so easily.
This should not forbid users to interact with the daemon in the way it was designed to work, in fact this should be totally transparent.
Your metaphor (ok, simile, you grammar nazis) isn't the greatest. Almost all combinations of food are harmless to healthy persons. Cooking (i.e., undercooking or blackening) can, indeed, allow or create toxins. But, that's fairly well understood by almost all cooks. Very little chemistry is needed to determine if a food is toxic: most of the time you can tell by the taste.
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'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...
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...
Microsoft's problem is that they started out with single user (and single tasking) non-networked systems that had NO security at all. Apps programmers just did whatever they liked without any thought for permissions. Then MS just tacked on as little as possible later to add rudimentry multi-user (one at a time) support complete with some dirty hacks to make old software function in that environment, some more hacks to keep users from totally screwing things up, and some access control. They focused so hard on legacy support that they destroyed any chance to do things the right way.
They had an opportunity with OS/2 to escape from that with a legacy compatability box inside a more advanced system, but they decided to go with NT instead. Why they've never revisited the idea of a legacy environment inside a real OS is beyond me.
The result is applications that want to write in the program directories and worse, want to re-write themselves as the user that ran them to do updates with no real pressure to change until Vista. Vista has so many problems in itself that any problems are perceived to be Vista problems even when it's a 3rd party app that hasn't done the right thing. Also, MS decided to be user obnoxious with UAC rather than putting the apps in a "penelty box" to drive users to perceive them as old and clunky (and so drive them to update).
People use Unix of various flavors daily without root capabilities and sometimes with no way to get them on work machines. That's because Unix apps know that configs go in $HOME and that they're not likely permitted to re-write themselves. For single user home machines, a select group of config tools are suid root. The point is that it's not necessary to neuter security to permit painless operation.
If you are going to take competency of the admin into account when analyzing how secure a system can be, then you are pretty much already screwed.
No, you are screwed if you don't take the competency of the admin into account.
Besides, it's not just a question of competency, it's also a question of time. I'm not going to waste my time on a system designed by people who treat my time as being worthless.
Thinking like yours is the reason why security sucks so badly.
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.
And thats why you hand out MS like candy. ..., ... Brazil will be sitting in from of their computer
Some smart person in China, Russia, Serbia,
Australia, South Africa, the USA, Germany,
one day reading source code that they are interested in.
They will lol at the quality or think wow this is
neat until they see something out of place.
Then they go the the forum, chat room, blog or web page for 'help'.
Game over back door.
Best to just keep people using MS products.
MS is the backdoor.
Domestic spying is now "Benign Information Gathering"
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.
Sure there is. Try any default install of Fedora, CentOS or RHEL, and you will be able to run Firefox just fine with SELinux enabled.
How do you give a post a (Score 10, Enlightening)?
This is what I got from your post: I can define a role that allows its members to access defined sets of resources (files/directories/IP addresses+ports), where access is limited to those operations permitted for each resource, but only when using the application and protocol proscribed for each set.
This will be very useful to my work. Thank you.
There is no "copying". They all implement the same features and ideas designed by the same people for the same purpose. From NSA's, DARPA's et al. perspective, this is simply "dual sourcing" — what customers with huge budgets and strict requirements are supposed to do for redundancy.
They need them all for their multitude of servers. But since FreeBSD is better to begin with, you want it for your smaller establishment, unless already "married" to Linux for some other reason — just as I said before ;-)
The page you sent me to describes SEBSD as a port, not a "copy". Guess what? Firefox is a port too. Does it make it somehow inferior?.. Mozilla's primary target-platform is Windows — what you have on Linux is also, what you'd call "a copy".
In Soviet Washington the swamp drains you.
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
But what if his schizophrenia is a direct result of NSA activity?
The NSA actually has a very good track record in contributing to public knowledge of network security and hardening. The SNACs are amazing pieces of in-depth documentation for nearly any hardware and software platform.
If there is a back door, then it's a pretty good one.
Last time I checked, the linux kernel is maintained in source form. Reviewed by MANY developers, rather than just mine truly.
And we are talking about an OS used by geeks all over the place.
If there was an NSA backdoor, we'd most likely have found it by now.
Systems like SELinux are necessary to prove that things can be done. When intensely complex trust relationships and roles can be setup within a system, legislation can follow to mandate those controls. Imagine if the financial sector was required to fully track who accesses your information. Imagine if they had to limit access to your information based on which entity wanted the access. Imagine they should have to limit specific entities to specific types of access that can only be granted by following strict, fully auditable procedures. With a system like SELinux, those kind of things can be done. The private sector can't throw up their hands and say, "Oh, it's too complex. We don't even have the tools to do it with."
You have a valid question about security versus functionality but I don't get the sense that SELinux is too concerned with that. There are dozens of distros out there that will give you "functionality" straight out of the box. Ubuntu seems to be a popular distro for those who want things to "just work". It seems to me like SELinux is one of those tools in the toolbox that you use in specific situations that call for it. If you're running a desktop where you want to tinker with things all the time, SELinux is probably just going to frustrate you. On the other hand, if you're developing a financial network that is supposed to pass secure, encrypted data around and be resistant to attack, then you might appreciate the very finely grained controls that are available in SELinux.
The geek side of NSA is excellent and they've done a tremendous job with the US governments electronic security infrastructure. The political side is not so good but it is fortunate that we have rather fast turnover for elected officials so that they can't do too much damage.
It's not perfect.
What does the most harm is when any government agency is given too much power by the laws that are enacted. Then you should point the blame at the legislature and the executive.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
yes, pretty much that's it - but, truly, don't say i didn't warn you about it being horrendous!
basically, "roles" and "contexts" can "track" different stages in your application, across different boundaries. the triggers between boundaries are typically things like "exec()" is the most obvious one, but you can explicitly tell selinux - via a system call with a c interface - to "change context right now, please".
typically this function call is made in a PAM module, and in this way, when someone authenticates, the application gets to change "context" - and of course because it's done in PAM there's no code changes required to your application.
but there are many more system calls on which "context changes" can be made, thus subdividing your application up even further.
the above scenario i described - where ssh shell access is only permitted from one set of ip addresses by one set of users, and sftp is allowed from a different set of ip addresses by a different set of users - is the extreeeeeme case.
the "default" setup that selinux has is of course to "allow all incoming port 80 and 443 for any user on any interface" for httpd, etc. etc.
Especially in open-source code designed to enable systems to meet certification requirements for sensitive US government use.