Slashdot Mirror
New Release Of NSA SELinux
rstewart writes: "The NSA has released a new version of SELinux for public consumption. It is based on the 2.4.9 kernel and the utilities patches are known to work on Redhat 7.1. More information and the source can be found at the NSA SeLinux site." You can read the what's new for more information.
Aside from the NSA, has anyone taken the time to audit the code?
My compile keeps hanging on NSABackdoor.h
The sole purpose of the NSA is to spy on you, now why are they trying to make your system more secure?
Incorrect. Read the NSA's charter.
Pay attention to section 1, Article 5, Section 3 et. al. The NSA also is charged with creating standards for the security of information held in DoD computers (specifically), other govt. computers (generally), and promulgating those standards for use in other systems. Here is a nice link to the NSA's computer security guidelines if you haven't seen them.
Yes, the NSA spies on people. No this isn't nice. Yes, the government of the USA does some awfully screwy things, like the DMCA. Tarring the whole government with the same brush is simple-minded.
Besides, the code is available for your perusal. If you think the uberspooks have put in a back door, get to work and find it!
Is the NSA responsible for figuring out the best ways to lock down whatever OS's the various government agencies of the U.S. use? Reason I'm asking is because seems like recently (or kinda-recently) there was an article here on /. with a link to the NSA's guidelines for securing Win2k. I'm sure the NSA has reasons that I don't even want to know about for running both their own build of Linux and a tightened-up install of Win2k, but I'm just curious as to the extent of their influence on other agencies' software choices.
Do other agencies just follow along with the guidelines the NSA sets forth, try to get independent advice or go it alone? Financially, at least, it would seem like going with the NSA's guidelines would be the way, since the information is more or less public (at least it is in these two instances) and there wouldn't be any time or money spent on third-party tripe (bids, negotiations, etc) or independent research.
My sigs always suck.
First try and wrap your brain around this concept: The NSA has TWO distinct missions -- to spy on foreign nations on behalf of the US government, and to keep foreign nations from spying on US govt. and businesses. People tend to forget about that second part. Knowing government beaurocracy, it's not at all unlikely that the spy-on-other-folks department and the keep-other-folks-from-spying-on-us department are involved in a turf war, or are working at cross-purposes.
Second: the NSA secure linux is a patch to the standard Linux kernal. If you are paranoid about them trying to do somthing neferious, download the source and diff it against the baseline code. It's pretty hard (but not impossible) to hide a backdoor in source. Paranoid types, make sure you trust your compiler [as well as any other binary that touchs the code as it's being transformed from source to executable] If the NSA wanted to hack your box, they have a lot of better ways to do it than releasing a GPL'ed trojan. Give them some credit -- they are not that stupid.
This is a Good Thing. Having a respected government agency endorse Linux gives it huge amounts of credibility. [OK, geeks may not trust/respect the NSA, but you can be sure that CEOs and PHBs do.] Believe it or not, occasionally the US gvt does manage to Do The Right Thing, even if it's unintentional.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
The main difference is that they address totally different security needs. Grsecurity is focused on preventing various common buffer overflows, race conditions, port scans, etc. It doesn't really do anything to make the basic Unix permissions any more fine grained than the currently are.
On the other hand, the SELinux is focused on exactly this. It allows you to specify much more finely grained permissions for users and processes. This actually complements the grsecurity work. SELinux is focused on minimizing or containing the damage that can be done with a given application. This can both minimize the things that a buffer overflow can do, and minimize the evil tricks that a user might be able to get away with using installed software. For example, a user could restrict what directories netscape is allowed to read and write to. Or an admin could restrict 'top' to opening the kernel read-only so that a buffer overflow wouldn't enable root access. Or preventing even 'root' from changing important system-level libraries and binaries.
All sorts of really neat things are possible. The downside of course, as you mentioned, is more complexity to administer. But it doesn't make sense to compare Grsecurity and SELinux. They address different security shortcoming of Linux.