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...
A few years ago, while browsing around the library downtown, I had to take a piss. As I entered the john, a big beautiful all-American football hero type, about twenty five, came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was "straight" and married -- and in any case I was sure I wouldn't have a chance with him.
As soon as he left, I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy young ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as a man's wrist. I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a heavy rimmer and had lapped up more than one little clump of shit, but that had been just an inevitable part of eating ass and not an end in itself.
Of course I'd had jerkoff fantasies of devouring great loads of it (what rimmer hasn't?), but I had never done it. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of the world's handsomest young stud.
Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking.
I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract? I gave it a lick and found that it tasted better then it smelled. I've found since then that shit nearly almost does. I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big brown cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was the donor of this feast wasn't there to wash it down with his piss. I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my hankercheif, and stashed them in my briefcase.
In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole -- not an unreasonable recourse in moments of desperation or simple boredom.
I stored the turds in the refrigerator when I was not using them but within a week they were all gone.
The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process. I often think of that lovely young guy dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did,bring to a grateful shiteater.
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.
just keep focused on the smoke (& mirrors), & never mind the fire. it'll go out by itself after a while? there might not be much of anything left, butt that's not yOUR problem? alternatively, you can be more helpful than you might have imagined. there are still some choices. if they do not suit you, consider the likely results of continuing to follow the corepirate nazi hypenosys story LIEn, whereas anything of relevance is replaced almost instantly with pr ?firm? scriptdead mindphuking propaganda or 'celebrity' trivia 'foam'. meanwhile; don't forget to get a little more oxygen on yOUR brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.
http://news.yahoo.com/s/ap/20071229/ap_on_sc/ye_climate_records;_ylt=A0WTcVgednZHP2gB9wms0NUE
http://news.yahoo.com/s/afp/20080108/ts_alt_afp/ushealthfrancemortality;_ylt=A9G_RngbRIVHsYAAfCas0NUE
http://www.nytimes.com/2007/12/31/opinion/31mon1.html?em&ex=1199336400&en=c4b5414371631707&ei=5087%0A
is it time to get real yet? A LOT of energy is being squandered in attempts to keep US in the dark. in the end (give or take a few 1000 years), the creators will prevail (world without end, etc...), as it has always been. the process of gaining yOUR release from the current hostage situation may not be what you might think it is. butt of course, most of US don't know, or care what a precarious/fatal situation we're in. for example; the insidious attempts by the felonious corepirate nazi execrable to block the suns' light, interfering with a requirement (sunlight) for us to stay healthy/alive. it's likely not good for yOUR health/memories 'else they'd be bragging about it? we're intending for the whoreabully deceptive (they'll do ANYTHING for a bit more monIE/power) felons to give up/fail even further, in attempting to control the 'weather', as well as a # of other things/events.
http://video.google.com/videosearch?hl=en&q=video+cloud+spraying
dictator style micro management has never worked (for very long). it's an illness. tie that with life0cidal aggression & softwar gangster style bullying, & what do we have? a greed/fear/ego based recipe for disaster. meanwhile, you can help to stop the bleeding (loss of life & limb);
http://www.cnn.com/2007/POLITICS/12/28/vermont.banning.bush.ap/index.html
the bleeding must be stopped before any healing can begin. jailing a couple of corepirate nazi hired goons would send a clear message to the rest of the world from US. any truthful look at the 'scorecard' would reveal that we are a society in decline/deep doo-doo, despite all of the scriptdead pr ?firm? generated drum beating & flag waving propaganda that we are constantly bombarded with. is it time to get real yet? please consider carefully ALL of yOUR other 'options'. the creators will prevail. as it has always been.
corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7
as there are no benefits, just more&more death/debt & disruption. fortunately there's an 'army' of light bringers, coming yOUR way. the little ones/innocents must/will be protected. after the big flash, ALL of yOUR imaginary 'borders' may blur a bit? for each of the creators' innocents harmed in any way, there is a debt that must/will be repaid by you/us, as the perpetrators/minions of unprecedented evile, will not be available. 'vote' with (what's left in) yOUR wallet, & by your behaviors. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi glowbull warmongering execrable. some of US should consider ourselves somewhat fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate. it's right in the manual, 'world without end', etc.... as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on
GNAA Sperm Races
To help fund our PR2TMP we are holding GNAA Sperm Races:
http://www.gnaa.us/penis-rocket-to-the-moon/spermraces2008/enter.html
Cum in a cup at our event and we will give it to our Lesbian Nigger who will toss all of the mixed semen into her vagina and we'll watch together on a big screen as the sperm race to her eggs!
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 think trusting a piece of software put together by a government agency who makes a living spying on its own citizens, is kind of like taking a gun and shooting your foot.
I don't care how open source it may be, I wouldn't touch that Linux version with a 10 foot pole!
No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
"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?
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.
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.