LWN: Comments on "RHEL certified at EAL4+"

RHEL certified at EAL4+

kreutzm — Wed, 11 Jul 2007 18:38:14 +0000

Two points:

a) EAL 4 (or EAL4+) is the highest assurance level typically obtained comercially. Read: Everything higher is too expensive.

b) EAL 5 is not "better" than EAL 4. You have to compare the security targets or even better look which PPs are fulfilled.

c) LTP has been driven enormously by certification, IIRC.

RHEL certified at EAL4+ (versus SLES at EAL4+)

kreutzm — Wed, 11 Jul 2007 18:34:14 +0000

Hello,
as there are some factual incorrect statements, I'll have to correct them.

a) When certifying products you always have to specify the environment. So it depends on the sponsor. Maybe special hardware is required, but I wouldn't expect IBM to sponsor Linux on Dell hardware. Though technically it might behave the same. (Maybe a hardware dongle is required, but I really doubt it)
b) There is no extra math in EAL 4+. You'll need some semi-formal formulation for EAL 5, but formal (mathematical) proofs are only for EAL 6 and EAL 7. But you simply cannot afford it typically.
c) I would consider the PPs the security standard. EAL is only a metric, how much effort went into testing. It is called "evaluation assurance level". The same product may be evaluated to EAL 1, where mainly some documentation is reviewed and up to EAL 7 with mathematical proofs. Just in the first case you are not very sure, that the product does in fact fulfill its promise, while in the latter case you have the mathematical proof.
d) Yes, you always have to read the assumptions. You know, the first certificate for a previous mainstream operating system had networking and graphics turned off ...

But testing is very thourougly, so EAL 4+ is usually not easily breakable. Of course, if the admin usese "123" as root password and ignores all documentation, well ....

RHEL certified at EAL4+

jamesm — Tue, 19 Jun 2007 00:20:02 +0000

Please correct me if I'm wrong, but there appears to be no security labeling of memory regions or of network connections.

SELinux provides MAC coverage for shared memory (and indeed all Sysv IPC mechanisms. For networking, there are two forms of external labeling (CIPSO and a new IPsec based scheme), as well as local labeling of packets integrated with iptables. There's also coverage at the socket API layer, so all newtworking is covered, as well as some protocol-specific coverage for things like Unix domain sockets and Netlink.

RHEL certified at EAL4+

jd — Mon, 18 Jun 2007 23:28:31 +0000

EAL4+ is fine, but as others have noted, it's only an assurance that a set of criteria has been met. It is not actually a security audit, per se, unless the specific implementation of the Common Criteria actually includes a security audit. I believe the highest rating for a general-purpose OS is EAL5, and Windows 2003 ranks EAL4, so 4+ seems to be a little on the old side anyway. Who wants to be known as only a little better than Windows on security?

Now, certain Government uses require certain EAL levels, so this will have an impact on who uses Linux. Maybe not a huge impact, but an impact nonetheless. That, in and of itself, is a major bonus, even if the label has little real value.

There are a few things that surprise me, assuming I read the PR correctly. Please correct me if I'm wrong, but there appears to be no security labeling of memory regions or of network connections. These are fairly significant security additions and have been considered an important part of mandatory access controls for a long time.

The next thing that surprises me is that I saw nothing obvious about a kernel or glibc security audit. A thorough audit of these two would be well within the capacity of IBM and would eliminate weaknesses at the critical points within the system. Any weakness in those two components will be shared with virtually all applications, so closing them would seem critical for true assurance.

I hope the EAL4+ tests make their way into the Linux Test Project, the way the other EAL tests have, and I also hope that some of the hardened Linux distros use these tests to show what level of security they are equivalent to, whether they are certified or not. It would be healthy competition if a solid hardened distro could show itself to be comparable or superior to the certified version of RHEL5 in terms of standards and security. Not because I have anything against Red Hat, but because it will boost efforts in the security arena.

RHEL certified at EAL4+ (versus SLES at EAL4+)

Wol — Mon, 18 Jun 2007 21:08:04 +0000

If I may quote Einstein:

"As far as the laws of mathematics refer to reality they are not certain; and as far as they are certain they do not refer to reality"

So the maths is no guarantee that things will actually work in the real world...

Cheers,
Wol

RHEL certified at EAL4+ (versus SLES at EAL4+)

smoogen — Mon, 18 Jun 2007 00:08:04 +0000

In most cases the subprofiles are more important for areas of 'assurance'. CAPP is the 'lowest' level profile and is somewhat equivalent to C2 from the old Orange Book. LSPP is supposed to be equivalent to B1 and the RBAC+LSPP is supposed to move towards B2 (though I have heard differening opinions on this).

http://www.dynamoo.com/orange/orangechart.htm

In any case getting a CAPP/LSPP/RBAC is usually tied to a specific hardware+software combination. I could put the same software on a Dell server and not be 'certified' due to the fact that it requires some hardware dongle thingee that was needed for the protected path on the IBM or HP box.

Getting SuSE to be certified to EAL4+ on LSPP/RBAC is probably underway, but may be much harder to do... Selinux was written pretty much to help meet various EAL high level specifications with all the extra Math ready to be documented when asked for. AppArmour was not and you have to go through a lot of extra hoops to show that it meets the mathematical criteria.

I am not saying it is not impossible.. but that its a lot of extra hoops that in the end SuSE may decide are not a large enough incentive for sales.In the end, EAL certification is not a security standard. One can have a CAPP/LSPP/etc system that any script-kiddie can break into and mutiliate.. EAL is meant to be a validation that if you have a LSPP/RBAC system AND the sysadmin knows what they are doing.. the system should be robust in some sort of environment (which is usually described as being a non-threatening/trusted one.. eg NOT the internet.) Thus in the end having various EAL certs mean that you can be bought/sold to customers who have this requirement listed on their ISO9000 or some other audit list.

RHEL certified at EAL4+

jamesm — Sun, 17 Jun 2007 13:55:01 +0000

Indeed, EAL4+ is an "evaluation assurance level". What is being evaluated is critical, and probably the important thing to note with this is that LSPP (Labeled Security) is included. You can read the spec here, www.commoncriteriaportal.org/public/files/ppfiles/lspp.pdf Essentially, what this means is that Mandatory Access Control has been implemented at the highest assurance level possible with an off the shelf operating system. The requirements here go way beyond userids. I suspect what you are referring to is CAPP-specific, which is a different protection profile that Linux has already been certified against.

RHEL certified at EAL4+

pjm — Sun, 17 Jun 2007 11:54:26 +0000

To be more explicit: EAL4+ by itself does not indicate a security level, it indicates a degree of assurance that the specified protection profiles are met. As I understand it, getting EAL7 in protection profiles LSPP, RBACPP and CAPP doesn't tell you much about how safe it is to connect your computer to the Internet beyond any other system that supports the notion of user-ids. See also the comments http://web.archive.org/web/20060527063317/http://eros.cs.... on Windows 2000 SP3+ getting an EAL4 for CAPP, where it is claimed that EAL4 doesn't require examining or testing the software, just examining the paperwork surrounding the creation of the software.

RHEL certified at EAL4+

henning — Sun, 17 Jun 2007 10:29:51 +0000

Thank you for pointing this out, i was not aware of it. So the RBAC and
LSPP profiles are not tested in SLES.

RHEL certified at EAL4+

xose — Sun, 17 Jun 2007 09:54:02 +0000

not at the same level:

SLES-9 ( http://www.bsi.de/zertifiz/zert/reporte.htm#mittlere_Systeme ):
Controlled Access Protection Profile, Issue 1.d

RHEL-5 ( http://www.niap-ccevs.org/cc-scheme/st/?vid=10125 ):
Controlled Access Protection Profile, Version 1.d
Labeled Security Protection Profile, Version 1.b
Role Based Access Control Protection Profile Version 1.0

RHEL certified at EAL4+

henning — Sun, 17 Jun 2007 09:01:17 +0000

Nice to see that now two major enterprise distribution exists that support this security level. SLES was certified for this level more than two year ago, though: announcement.