Slashdot Mirror
Red Hat Linux Gets Top Govt. Security Rating
zakeria writes "Red Hat Linux has received a new level of security certification that should make the software more appealing to some government agencies.
Earlier this month IBM was able to achieve EAL4 Augmented with ALC_FLR.3 certification for Red Hat Enterprise Linux, putting it on a par with Sun Microsystems Inc.'s Trusted Solaris operating system, said Dan Frye, vice president of open systems with IBM."
So does CentOS get some sort of auto cert then?
The law is not an ass. No really.
This is roughly equivalent to "B" in the well-known U.S. "Orange Book" security standard. Previously all commercial off-the-shelf OSs were rated C or below, and had trouble even getting that (NT 4 got C only if the network was physically removed).
The letters correspond with school grades: A is excellent, B is ok, and C is barely adequate.
--dave
davecb@spamcop.net
What does that have to do with RHEL? It is designed to be a stable server platform. Your post has so little to do with the article, I'm going to need to ask you to RTFM.
It's worth pointing out that this is actually equivalent to a "B1" TCSEC rating http://en.wikipedia.org/wiki/TCSEC and that it's impossible to get any higher rating for a commodity operating system. This is all specifically due to the SELinux support in Red Hat EL (and consequently CentOS and Fedora and other derivatives). Supposedly SuSE/Novell are trying to achieve this rating ATM but due to the limitations of AppArmor compared to SELinux it seems unlikely that they will.
Did I miss something? Is it "Asshat Monday" and I didn't mark it on my calendar?
EvNGGG I cannnmmmmssee it's mngaTROLL, numbbehebehbehnuts!
Have you read my blog? Neither have I.
That was a cut and paste troll.
They're never on topic, they just show up in random Linux articles.
Free the Quark 3 from asymptotic confinement! Bring your charm! Don't get down! All colours and flavours welcome!
Are you naturally this off topic, or did it take effort.
Ignoring for the the moment I agree with *some* of your points, Linux on the desktop has nothing to do with this post, it is entirely about Linux as an enterprise grade server OS.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
--dave
davecb@spamcop.net
The letters correspond with school grades: A is excellent, B is ok, and C is barely adequate.
Just wait until the "No OS Left Behind" program gets passed.
Hmmm...I'm getting conflicting information. According to this Microsoft White Paper (sorry, Word .DOC format), the EAL4 + Augmented with ALC_FLR.3 rating, which BTW, both Windows XP SP 2 and Windows 2003 Server SP 1 also have, is only equivalent to C2, which is the same rating that NT 4 received. IOW, this cert doesn't really mean that much.
My blog
Check the slashdot story when Microsoft OS'es got a similiar certification.
Let's compare the comments at the end of the day.
Microsoft is only certified CAPP/eal4+. That is not LSPP/RBAC which is much harder and more secure.
Sorry for the naive question in advance, but I was under the impression that some flavors of BSD (OpenBSD?) were extremely secure as well. Is that not so? In that case, wouldn't a BSD version be more suitable for secure/sensitive installations?
Again, please don't treat this as a flame. I'm just curious to know how BSD ranks vis a vis other OSes, especially Linux, and especially in terms of security.
Make no mistake; the OS does make a good deal of difference for security in some respects. However, it seems to me that most security leaks come from HUMAN error. With respect to that, Red Hat does nothing (nor could I expect it to...). Nice to know that Linux can at least be recognized this way, at least.
I don't think it's a flame. All that this certification means is that a government department tested specific aspects of security on specific hardware. It shouldn't be thought of as anything more, it's just a rubber-stamp for administrators that don't want to understand security.
Igor Presnyakov stole my hat
Any idiot can build a Linux system which runs absolutely no services whatsoever and SELinux to delegate authority appropriately with modern RedHat versions.
What's more interesting is does the resulting system do anything useful? Web server? Mail server? DNS? File server?
Do you lose certification as soon as any extra services are running? In which case, it's fairly meaningless because the certification only applies if the system is broadly useless.
No, because without the certification, secure/sensitive installations aren't allowed to use those flavours of BSD (or any other uncertified product). If there's no other way of performing a function, it might be justifiable, but it'll be a brave sysadmin that pursues such a course.
The above has no bearing on BSD's relative technical merits and demerits compared with OSs that have achieved CC certification.
I'm going to venture that you don't know much about serious professional level computer systems. I'm going to discuss, point by point, why you are just flat out wrong and not thinking clearly about many things.
.deb and .rpm). The constant upgrade cycle where you discover that your most recent upgrade broke something has nothing to do with the process of compiling software per se, but interoperability between different software. The Microsoft WSUS updates are constantly breaking applications, and this is even more exaggerated in the server market.
A)Many different versions of Linux have various binary packaging systems so you don't have to compile things, Debian and Redhat being the two most popular (yum and synaptic/
B)The vast majority of mission critical infrastructure systems that the internet and all high level computing systems run from the command line. Switches, routers, cores, these are the bread and butter of what makes the internet work, and nobody says that a developer has failed when they produce one of these that works. Frankly, you are just being hyperbolic, failure as a developer means that your application does not work. These devices and applications do work, and as anyone familiar with a command line interface knows, it is usually far simpler to troubleshoot a problem in an environment that you have complete control over (like the command line) than it is in some hairbrained GUI that is made to pander to people like yourself who consider themselves technical users but think that command line interfaces are bad.
C)Linux documentation is far superior to that of Windows, because the API's and sourcecode are all available. Learn how to program, don't blame the difficulty of programming on inferior documentation and instructions. There are people who do what they want in linux, just because you can't, doesn't mean that there is something wrong with linux. Rather, it probably means you are not that smart. The entire notion that linux is an alien environment presupposes a fetish for windows.
Your conclusion is complete bunk, because your arguments don't hold any water. Basically, what you've just done is ranted. Linux does not suck in the regards you listed. Nothing is perfect, and everything can be improved, but you simply don't make a nuanced point like this.
Besides which, this thread was about Security!
I read that link, but is the following just concidence? "Certificate Date: 01 April 2007" Hmm....
Not only that, but those Windows is only certified on specific hardware, while the same is not true of the RHEL5 cert. Thanks for pointing that out. It shows once again that a solid stable system like RHEL5 is indeed more secure than Windows, even if only it is because the military believes it to be so. But I'm guessing that military IT might know a thing or two about good systems security. ;)
My blog
This is actually a complex issue that cannot be summarized as "much harder and more secure".
EAL4+ refers to the assurance level applied to the software in question. It measures how well the software is implemented - in some sense what the probability of undiscovered holes is.
EAL4+ is actually a rather low level of assurance. After all, Windows can pass EAL4+.
CAPP. LSPP, and RBAC are protection profiles that refer to the protection policy enforced by the software. CAPP coveres things like access control lists and protection bits, LSPP covers mandatory security policies, like the Bell and LaPadula policy. RBAC covers role based access control. These are all security features.
You can have lots of security features and low assurance. You can have few security features and high assurance. You can have lots of security features and high assurance.
The old Orange Book scheme used a single dimension to rate the level of security. Both features
and assurance went up as you went up the scale. This was done to keep the system simple.
The Common Criteria is vastly more complex and confusing, and it is much harder to compare the level of security of two different products with Common Criteria evaluations.
very very rough equivalents:
Orange Book Common Criteria
C2 ------ EAL3 and CAPP
B1 ------ EAL4 and LSPP
B2 ------ EAL5 and LSPP + covert storage channel protection
B3 ------ EAL6 and LSPP + covert storage and timing channel protection
A1 ------ EAL7 and LSPP + covert storage and timing channel protection
These equivalents are VERY rough, because LSPP doesn't really consider the issues at the higher
EAL levels.
When you use Linux for your commercial needs (which this is clearly intended for), you don't recompile kernel every week. The box stays the way it is unless some major security related updates are needed. You schedule downtime to make any changes and you are lucky if you get 1 hours of downtime a year.
This is not desktops, but huge servers. I have many many times tried to get such organizations to even apply one of our patchsets to their servers due to them hitting known bugs and it may take a couple of months for them to schedule it, and then only after testing it on their test servers and getting approval from management. For all of them, this is perfect and does not constitute any problems at all.
If you mod me down, I *will* introduce you to my sister!
Good news! It's ready!
;)
A) You don't have to compile anything. But you can if you want to. And you can forget about all those dependency DLL-hell issues too that you get in Windows, if you use a modern distro with good package management. Then you just fire up the GUI, put a "tick" in the box for the software you want, and it gets it for you and installs it. It's easier than having to trawl through someone's web site for the right installer, manually download it, manually run the setup. And then find the installer won't remove the software properly when you want to get rid of it or find it needs some obscure runtime DLL you never heard of and don't know where to get.
B) I do take exception to the "force me to drop to the command line" bit. Why would you need to drop to the command line to edit a text file, assuming you needed to do such a thing? I do drop down to the command line quite frequently though - it's good for batch operations and scripting things together, but I use a graphical text editor if I need to edit text - I'm not a masochist! Having said that, I haven't had to edit a text file on linux for system administration reasons for nearly a year. It's not a constant occurrence, not anymore. Hardware - all auto detected on installation. All devices I've plugged in have just worked (no need to trawl manufacturer sites for the latest driver). GUIs for all common system administration tasks. As far as windows goes, anytime I have to directly edit the registry, you as a developer... oh, never mind
C) Help is better these days, but I agree is still patchy in places. And arrogant people do still exist on some of the forums (hopefully getting fewer all the time). But then, Windows help files were never that good either, and I don't recall getting any help from Microsoft unless I paid for it. Can't really think of a system where the help and service has been uniformly excellent.
The truth is, linux is not the system you are describing anymore. Maybe 5 years ago - it's come on a long way. Why not download a bootable Ubuntu Live CD and give it a go, just so you know what's it's like these days.
Basically, they tested a specific version. That specific version (not including any patches!) and type of setup qualifies for the rating.
... which makes me wonder how stripped down it was. Probably no networking, among other things, because, I can't think of much in 2k that hasn't had a security hole!
If there is a vulnerability that would affect that setup/version in it's configured state, then the rating is supposed to be withdrawn, the problem fixed, and the system resubmitted.
Someone has figured out that perhaps, it might be a good idea to not have the vault door sealed, and a hole drilled in the side of the wall, so they tell you to apply security patches.
For the windows 2k thing: It's evaluated configuration wasn't vulnerable to any of the security patches, therefore it remains.
XTS-400 (Wikipedia entry)
XTS-400
That particular system is rated at EAL 5. IBM's only achieved EAL 4.
OCO is Loco
True, but I also think that most average users would take a text-based configuration file, especially one with instructive comments, over the Windows Registry any day of the week.
I'm not saying that registry editing is a usual occurrence, but sometimes it needs to be done, and I would prefer clear text files every time. Especially those parts of the registry indexed on class GUID are really opaque.
For certification purposes, it really doesn't matter how secure the system is, but how secure you can show the system is.
I attended a presentation regarding these certifications from a manager at IBM, (I forget his name), that had taken several products through the certification process and he said that it is all about the documentation. For example, how many people working on BSD have the architecture, design and user documentation to prove that something has been designed securely? It might be secure and a lot of people may have reviewed it and declared it secure, (even the auditors), but without the corresponding documentation it can't pass certification. Why not? Well, without a design document, I can't verify the implementation actually does what it is supposed to. Also, without the user documentation, how do I know that I have to have certain services running for the behavior to be valid? The auditors are allowed to do anything they want to the system that isn't forbidden in the documentation. So, if it isn't documented that you can't turn off some security service, it is fair game. That's why the product, in a certain configuration, is certified and not any system that happens to run the OS.
I think this is why we will only see high levels of certification going to corporate sponsored OSes. Let's face it, most open source developers don't want to spend most of their time documenting their work - they want to actually do it. It is only when you have management that focuses on the certification process, and holds everyone accountable for proper documentation, that the requirements can be met.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
Integrity is an RTOS platform, not a general purpose OS. I've worked with their ARINC 673 product a bit, much standard UNIX functionality would break the guarantees made by an ARINC-compliant OS so it's just not present. Xen is a close enough approximation if you just want to partition the system off without using ARINC 673, but in order to get the same sort of certifications as Integrity (or VxWorks' ARINC 673 product for that matter) all the code involved with Linux - kernel, userspace etc. - would need a line-by-line code review, probable changes, and sign off.
GPL: Free as in will
Actually Military IT isn't the greatest. Too many young kids with not enough experience. However, the NSA does the accreditation and they, unlike the above poster states, are very good at what they do. The testing does'nt prove that the OS is more secure; it demonstrates that it is designed securely, and more importantly, that it has adequately tamper-resistant auditing and adequately rigorous permissions. That's why POSIX compliant OS'es aren't very convenient to certify; the permission systems are very different.
I'm a fairly technical user, not a tech god by any stretch of the imagination, but I know my way around. I know how to forward ports on my router, I do all my own CD rips from Grip, I can install most Windows versions without a problem, and I'm damned proficient at packages like Paint Shop Pro and the GIMP. In addition, I'm a gamer from back in the DOS/Win95 days, so concepts like editing undocumented system-critical settings (Registry hives) don't necessarily scare me.
That said, as much as I like the concept of Windows NT, I simply will not try it any longer until I hear that a number of problems have been solved.
A) Having to manually download software/worrying that nonstandard installation routines might scatter junk all over the file system and not remove it upon deinstallation. For that matter, I don't want to have to manually download and install anything, ever. Just to make this clear, never. Come up with either something akin to Ubuntu where I run Synaptic to install everything I need, or (if you absolutely have to) make it like Mac OS X where I just drag and drop the folder.
B) Any time I'm forced to to edit the Registry by hand (without documentation, to boot), you as a developer have failed. Back 10 years ago, this may have been acceptable. In this day and age, it isn't. Furthermore, while once in a blue moon I may have to change a system-breaking internal file in Linux, in Windows it's a constant occurrence. Again, you have failed.
C) A troubleshooting guide instead of proper OS documentation does not cut it. Neither does a message board where half the time I'll be told to reinstall, 25% of the time I'll be told to run random diagnosis apps, and the other 25% of the time I'll get genuinely helpful people giving me contradictory answers. If I'm expected to jump to an alien computing environment you'd best make sure your documentation is up to snuff. Most Windows apps suck in this regard.
I'm an advanced user who's in favor of feature-rich OSes, but the bizarre, arcane, and technical details I have to jump through to achieve the same things that are comparatively simple in Mac OS X or Linux make Windows a deal breaker. You will never, ever, become successful on the server until idiocy like this is exorcised from the OS.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
No, it's not.
"EAL4 with CAPP, LSPP and RBACPP" means that RHEL5 on most all current IBM h/w can be very secure by people who care and know what they are doing.
"I don't know, therefore Aliens" Wafflebox1
This certifications at the EAL4 and up levels are all functional tests. That is the actual system is run. Software by itself cannot run. It needs the hardware. These types of certifications are designed to eliminate as many unknowns as possible. Any RHEL system should behave the same but can you guarantee that? Consider the simple case as a bug in a hardware driver in one system but not in the tested system. That said, it is reasonable to expect that all x86 type hardware similar to the eServers would achieve the same certification.
Also IBM paid a pretty penny for the certifications. They would rather their competitors pay for their own certifications.
I think Red Hat should send something to Steve Ballmer to rub this in his face... something along the lines of "Looks like you need to Get the Facts about Windows and Linux. Where are your lobbyists now?" along with a copy of the certification.
The confusion here is that this certification has nothing to do with exploits or kernel bugs (the form of security most people talk about on a regular basis). We're talking about CIA/NSA levels security. It's based largely on how finely-grained the system permissions are, so that an exploited application can't access any other files, open any other ports, etc., etc., as well as ensuring that a system can have multiple administrators, each with very limited scope of privileges (no single root account) and overlapping authority. It is known as MAC (Mandatory Access Controls).
RedHat Linux has MACs mainly because it took the mechanisms from the NSA's SELinux and rolled it into their own OS.
FreeBSD has a spin-off project called TrustedBSD which has actually been around longer than SELinux, and has had much more impact, with some of it's features having been integrated into other systems such as NetBSD and OS X. See: http://www.trustedbsd.org/ and http://www.freebsd.org/doc/en_US.ISO8859-1/books/
The difference, though, is that RedHat is a company, which wants to pay for certification so they can use it to market their product. FreeBSD/TrustedBSD isn't run by any large company with a deep financial interest in marketing the OS, so it's unlikely to go through the evaluation and certification process.
OpenBSD doesn't have any of those security mechanisms, but you can accomplish the application security part of it through extensive use of systrace. Both methods are difficult to use effectively in practice, and require a skilled an dedicated admin... not really cost-effective for 99% of companies.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Have a look at the Solaris man pages. Plenty of examples in them...
Don't feed the penguins
Not EAL-4 is not "TOP". Shame on the press release writers for spreading untruths.
Nor is EAL-4 the highest rating an OS product has achieved.
EAL-5 has been achieved by only one complex product in the world last I looked (BAE's STOP OS, a Linux look-alike in API/ABI running on an Intel CPUed platform) and it doesn't lose its security rating when connected to a network.
The value of the rating system is that it lets everyone see the criteria under which you were judged and the degree of excellence against those criteria determined by independent judges. But the person selecting the product has to know a lot about security to be able to understand the value provided. For example, it is easy to configure most EAL-4 rated OSs in such a way that they void their rating.
Having been the Product Manager during the STOP evaluation, let me congratulate Red Hat as achieving EAL 4 is a great achievement for their team (and was required of us before we could even submit for an EAL-5). May they now go on and undergo additional time, expense and pain in striving for a higher rating.
On a side note, FreeBSD does have MAC capabilities, and could probably be configured to pass at least EAL3 (not sure about the design verification requirements for getting EAL4), but like OpenBSD it lacks a massive, financially-interested organisation to sponsor it through all the testing. Note the RHEL5 was sponsored by IBM, not by RedHat, which gives a very clear indication of just how much financial backing is necessary to seriously attempt to get a system certified under the Common Criteria. Getting an EAL certification, as the Wikipedia entry on the topic states, is not a significant indicator of the security of a system. It just shows that the system was tested against certain criteria and passed.
"God, root, what is difference?" - Pitr, userfriendly
Good question. I haven't spent much time with any BSD system, but I've spent enough with SELinux (personal pet peeve: it's not `SE Linux', though `SElinux' or 'selinux' are acceptable) to know a bit about the difference. Pardon me if I wax loquacious...
In the computing world, the vast majority of security flaws come from bugs: improper handling of untrusted data leads to buffer overflows time and time again. Fix the bugs, and those security flaws go away. However, what about the ones you didn't catch? Someone is perfectly capable of discovering them, and exploiting them, until you discover the same problem and fix it. It's a vicious cycle, and you can never win: there's always another security hole, because there's always another bug. The security holes from bugs you haven't found yet are known as zero-day attacks, since any patches to the bugs have existed for zero days (or something like that).
The OpenBSD solution to the threat of zero-day attacks is to spend lots of time looking at its code, and reviewing its code, and testing its code, before vetting it to be `secure' enough to use. They do an excellent job: I don't know particulars, but I'd guess that an OpenBSD system out of the box is more secure than even a no-frills Linux distribution. They lock everything down, and generally don't run software that hasn't been tested thoroughly. Note, however, that you can poke holes in your shiny OpenBSD system by downloading and installing buggy code: Try any poorly-written FTP server, for instance, and watch your box get 0wnd.
The OpenBSD approach shouldn't really be seen as a choice, because every operating system that wants any hope at security needs to go through this process, of reviewing code time and again, and squashing those bugs dead. The deviation from other operating systems is the point where the code is declared to be `good enough', and put into production. OpenBSD developers are just really careful about declaring software to have reached that point. But they aren't perfect. Go to OpenBSD's website, and notice the text that says "Only two remote holes in the default install, in more than ten years!" Pretty good, right? Yup. However, as recently as three months ago, that read "Only one remote hole [...]". What gives? OpenBSD didn't handle some obscure IPv6 stuff right, and it was found that someone could run arbitrary code through this bug.
Does this mean that OpenBSD is a failure? No, though it does mean that they failed in their (rather lofty) goals at least twice (that we know about; I maintain they should change the banner to read 'Only X remote holes in the default install, in the last Y years, that we've discovered so far!'; but, that's just me). This doesn't (shouldn't) besmirch their reputation, and the OS is still one of the best, I'm sure. But ultimately, things like this will happen again; and inevitably, some cracker one day will write an OpenBSD exploit, and steal millions of credit card records because of an OpenBSD system which had a security hole, while the owner of the system believed it to be secure. In short, it's like most any other publicly available operating system: it tries really hard to be secure; and it is probably more secure than any of them, according to their accepted definition of having no security holes. It is an excellent goal, but it's ultimately impossible.
SELinux, which is the core of what was required of Red Hat Enterprise Linux 5 to pass this certification, is a very different approach to security. There're tons of things that go in to making SELinux, but I'll try to keep things as succinct as possible, at the risk of leaving (hopefully unimportant) things out. SELinux operates on the principle of `domains', which are made far more abstruse than they need to be. A domain is a