| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
RHEL 5 going for Common Criteria EAL 4 rating
RHEL 5 going for Common Criteria EAL 4 rating
Posted Sep 27, 2005 19:37 UTC (Tue) by jamesmrh (guest, #31622)In reply to: RHEL 5 going for Common Criteria EAL 4 rating by drag
Parent article: RHEL 5 going for Common Criteria EAL 4 rating
LSPP has some very specific security requirements, which are aimed at managing information at different classifications and users at different clearances. So, the direct value of this to non-govt types is unknown and historically limited.
What we're trying to do with SELinux, though, is make the technology available in the standard, current product, rather than an old fork of the OS like traditional "trusted" OS vendors. We're also trying to implement the technology in a more generalized way, so it can be re-used for other purposes. An example of this is MCS, which is an adaptation of MLS which allows users to assign security categories to files that they own.
There are several security technologies being rolled out for general use (Type Enforcement, MLS, MCS, RBAC etc), and rather than take a prescriptive stance, that is, to say "this is how your security should work", there's a lot of scope for users to innovate and feed their ideas back into the community.
The short answer to your question is that you get a bunch of security technologies which have not existed in a generally available, modern OS.
The certification will be for a specific configuration and on specific hardware, I believe, and I'm not sure which security policy (there are several mailing lists including the redhat-lspp list where these issues can be discussed in more detail).
(Log in to post comments)
RHEL 5 going for Common Criteria EAL 4 rating
Posted Sep 27, 2005 20:14 UTC (Tue) by bojan (subscriber, #14302) [Link]
>What we're trying to do with SELinux, though, is make the technology available in the standard, current product, rather than an old fork of the OS like traditional "trusted" OS vendors.
Good move. Do the same with GFS and Xen in RHEL5 and you'll have many more people jumping on the virualisation and cluster bandwagon. The current GFS/Cluster suite subscription fees are really not something your average company can afford. And yet, getting the hardware to run it almost is.
Bring it to the masses and see the adoption rate skyrocket.
RHEL 5 going for Common Criteria EAL 4 rating
Posted Sep 27, 2005 21:33 UTC (Tue) by drag (subscriber, #31333) [Link]
Ya, I've been following0 SELinux developements since it was just patches from NSA. It's pretty neat stuff and I've always been apreciative of Redhat/Fedora's work to make it more usefull for the average person.
Still kinda skirted around the issue, but it's a good enough answer so I'm happy. Just be carefull how it gets promoted, you don't want people to think: "Oh, look Redhat just reached the same level of security that Microsoft got back with Windows 2000 SP3." (which is obviously untrue)
RHEL 5 going for Common Criteria EAL 4 rating
Posted Oct 11, 2005 6:31 UTC (Tue) by Vladimir (guest, #33011) [Link]
Just wanted to comment on this:"LSPP has some very specific security requirements.... So, the direct value of this to non-govt types is unknown and historically limited."
I don't need to be a government type to be able to use LSPP or Type Enforcement or RBAC for everyday business.
How on Earth would you let sysadmins to use root and in the same type to not have access to classified data stored on the servers the run?
Regards,
VG
RHEL 5 going for Common Criteria EAL 4 rating
Posted Oct 12, 2005 5:07 UTC (Wed) by etbe (subscriber, #17516) [Link]
The administrator has to perform tasks such as fixing file systemcorruption, backing up data, and installing new applications (including
custom applications). These tasks are not compatible with preventing the
administrator from accessing secret data.
We have a secadm_r role for security administration which can be separate
from the sysadm_r for general system administration. This is currently
an experimental feature and is designed to be discretionary in nature.
We can't entirely prevent the sysadm from doing the wrong thing in regard
to security administration, but if they do so then they can't claim it to
be an accident, mistake, or an issue where their duties were unclear.