LWN.net Logo

Red Hat and IBM get certified

Red Hat and IBM recently announced that Red Hat Enterprise Linux 5 (RHEL5) has earned the highest level of security certification achievable by commercial off-the-shelf operating systems. The certification is applicable when RHEL5 is running on IBM hardware, but all of the software is freely available, which may reduce the worries of customers regardless of which hardware they are considering running Linux on. The Fedora and CentOS distributions will immediately benefit, because they use the same software and SELinux policies, but other distributions can use the information as well.

The certification that RHEL5 achieved comes from one of the most acronym-dense regions of the internet, which is, perhaps, unsurprising for a partnership between industry and the US government. Here is how the press release puts it:

[RHEL5] has been approved by the National Information Assurance Partnership for Common Criteria Evaluation & Validation Scheme [NIAP-CCEVS] at Evaluation Assurance Level 4 (EAL4+) for Labeled Security Protection Profile (LSPP), Controlled Access Protection Profile (CAPP), and Role-Based Access Control Protection Profile (RBAC).

The NIAP is overseen by the US National Security Agency (NSA) and exists to create and administer certification programs like CCEVS.

The various protection profiles list the security requirements that need to be met to be certified. CAPP is concerned mostly with standard UNIX-style users and permissions, with some audit requirements thrown in. LSPP and RBAC are concerned with the security capabilities provided by SELinux along with auditing requirements. The profiles document the behavior that is expected while the testing verifies that the system does indeed behave that way.

These kinds of certifications are nice, in a checkbox kind of way. There are many organizations that cannot or will not buy products that are not certified for a particular level and protection profile. Windows Server has been certified at EAL4, so filling in this checkbox for Linux may well remove a barrier to Linux adoption in some places. Obtaining certification at this level is great deal of work; Red Hat and IBM are to be commended for spending the time and money to get to this point.

That being said, what does an EAL4+ mean for the security of servers that run RHEL5? As we said in late 2003, when (pre-Novell) SuSE teamed up with IBM to get an EAL2+ certification, the answer is, unfortunately, not much. It would seem that EAL4+ is a big step up from EAL2+, which it is, but not in the kinds of protections it provides. The EAL level is completely driven by how much testing and documentation go into the certification; how much "assurance" there is that the profile is met. The same profile (CAPP) was used in both.

In addition, the protection profiles are limited to:

a level of protection, which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well-funded attackers to breach system security.

This puts most, if not all, interesting security threats outside of the scope of the testing. Adding two additional protection profiles, as was done this time, is certainly significant, but they still operate under the "no hostiles" caveat.

Kernel hacker James Morris comments on the certification:

A lot of people thought it would be outright impossible to get an open source OS certified at this level. Not only were they wrong, but we've done it in a way which makes it part of the mainline kernel, upstream userland, and integrated into standard distributions. It is not some out-dated, incompatible and outrageously expensive fork of the OS, as has historically been the case with trusted OSes. "Military-strength" security is just now just another feature you get as standard in Linux, and it receives the same testing and community benefits as the rest of the OS.

Evidently, "military strength" security is only able to resist its own users making mistakes rather than a concerted effort by an enemy, but this is still a marvelous accomplishment.

Perhaps the most unfortunate part of this certification process is that it is likely to vastly underestimate the abilities of an SELinux equipped system. It would be very interesting to see what kind of protection profile could actually be accommodated by RHEL5; it is likely to be much stronger than any we have seen from CCEVS. But, given that customers are typically interested in the checkbox much more than security, we will probably never know.


(Log in to post comments)

Red Hat and IBM get certified

Posted Jun 21, 2007 4:34 UTC (Thu) by ab (subscriber, #788) [Link]

To be fair, EAL4 with CAPP certifications were achieved by IBM+RedHat and IBM+Novell for RHEL4 and SLES9 as well, in 2005 and 2006. This certification brings us EAL4+ with CAPP,LSPP, and RBAC. Linux distributions have been on par with Windows EAL-wise for couple of years already, and now RHEL5 is exceeding it.

While it is true that much of work goes into documenting process during certification, I can say that there is substantial development work as well. We've spent 9 months while doing RHEL4 certification in Russia (Russian certification body uses Common Criteria as a standard but doesn't accept existing certificates obtained in other countries), and that included also low-level analysis of the assembly code in several (~10 or so) packages that were different after control rebuilds of RHEL4. Multiply that by architectures (x86, x86_64, ppc64, S/390) and a lot of time spent to explain Linux distribution development process, including build farms and full distro rebuilds, you can get an idea how hard that can be.

The net result is that those certification efforts also bring us to better documentation. For example, High Level Design documents could serve as a good basis for general Linux-based cirricula.

Red Hat and IBM get certified

Posted Jun 21, 2007 23:17 UTC (Thu) by smoogen (subscriber, #97) [Link]

--------------------
In addition, the protection profiles are limited to:

a level of protection, which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well-funded attackers to breach system security.

This puts most, if not all, interesting security threats outside of the scope of the testing. Adding two additional protection profiles, as was done this time, is certainly significant, but they still operate under the "no hostiles" caveat.
--------------------

As far as I could find out 2 years ago.. there is no Certified Protection Profile that does not have this caveat. At some point in the well-funded hostile profile it goes like:

Hostile party finds sufficient threatening manner in order to go around physical/system security via kidnapping, torture, or other means.

Things that an OS can have very few protections against.

active response and adaptation

Posted Jun 22, 2007 14:00 UTC (Fri) by kirkengaard (subscriber, #15022) [Link]

A hostile environment is not plannable. Hostiles do not exclusively follow known, dependable routes that can be routinely secured, and determined hostiles will not give up once the usual routes into a system prove to be moderately secure. What a system evaluated EAL4 gives you is a reliable platform that can be kept secure through active response and adaptation to threat, or further secured by additional checks, but you're not going to get "off the shelf" EAL7 (Formally Verified Design and Tested) without the system being a "device" rather than software. EAL7 ceases to be a usable "toy" because nobody classifies hacker toys for EAL7 - spending that kind of scratch is reserved for special-purpose, secure, locked-down functionality.

It is pointless to whine about EAL4+ being untried in hostile environments, because that's not what it's for, and the mild kind of "hostile environment" a server room will see is secured by a systems administrator with other tools to work with in addition to default operating system security. You're being silly.

EAL4+ and no auditability?

Posted Jun 22, 2007 18:50 UTC (Fri) by ljt (guest, #33337) [Link]

How is it possible to be EAL4+ with a policy framework (selinux) that is not fully auditable?
I know, every thing is open source you can see every thing, etc.. BUT how can I know which policy I am currently running:
semodule -l gives you the list of module currently loaded but what is in those modules? (hint: the .pp lying on your fs doesn't qualify..)

EAL4+ and no auditability?

Posted Jun 24, 2007 16:28 UTC (Sun) by jamesm (guest, #2273) [Link]

One approach to this would be to export the currently loaded policy via selinuxfs so that it can be verified and analyzed.

Just added this to the todo list:
http://selinuxproject.org/page/Kernel_Development#To_Do_List

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds