Submitted by “Red Hat and IBM recently announced that Red Hat Enterprise Linux 5 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.”
YAY!
But I still think SELinux is a great idea, but an overly complicated implementation.
The fact the many admins turn it off due to this complexity is a real problem.
Selinux is complex, but it’s RBAC (Role based access control) done correctly (unlike some alternatives).
I just wish all distros would adopt redhat/fedora like security (e.g. selinux and (pax or exec-shield)).
The article is wrong.
This certification will have absolutely no certification effect on Fedora or CentOS distributions as it might seem to imply.
These certifications are only good for a specific product, configuration, environment, etc.
While others may be able to use some of the configuration information, they will never be considered equivalent in certification status.
The article doesn’t say (explicitly) that Fedora or CentOS will gain certification from this. Nor do I think it implies this. What it does say, however, is that the two OSs will benefit from this, which I definitely think they will. Much in the same way that OpenSolaris benefits from the certifications and advancements achieved by Solaris (as they share mostly the same code base), similarly Fedora and CentOS benefit from the certifications and advancements of Red Hat. It lets them say that their free and open solution is fundamentally based upon (if not almost identical) to the commercial “Government-Certified Military Grade” solution from Red Hat. So no, they won’t gain certification from it, but they can definitely gain a significant amount of clout from it.
Anybody that cares about or actually requires those certifications will know the difference, and will not be able to use Fedora or CentOS just because “it is based on something that is.”
While it may give some “fuzzy warm” feeling to some individuals, government entities will not be affected in any way by it.
That was my point.
And yes, to me, it does somehow imply that other distributions based on RHEL will receive some “status” indirectly from this certification. Matter of opinion.
If you work for the US Government (I do), the requirements are simple, if an operating system is on the NIAP approved list, it can be used within DoD. While RHEL being certified at EAL4+ might help it get accepted by DoD, it does nothing for either Fedora or CentOS since neither have been evaluated. And because they share parts of a common code base does not mean does not mean either OS has gone through a Common Criteria Evaluation.
And one other thing to note, the evaluation report clearly states that a GUI was not used as part of the evaluated configuration (link included):
http://www.niap-ccevs.org/cc-scheme/st/st_vid10125-vr.pdf
o While the TOE distribution media includes a Graphical User Interface (GUI), it is not installed by default, is not part of the Evaluated Configuration and was not evaluated.
If one was to compare this to either Trusted Solaris or Solaris 10 with Trusted Extensions where the GUI is an integral part of the trusted environment, this is a serious shortcoming and could possibly hamper implementation in some environments.
I think the circumstances where it could hamper deployment are going to be extremely rare. This would mostly have an impact in situations where RHEL5 was going to be deployed as a workstation. RHEL 5 is almost exclusively going to be considered for deployment as a server in these environments which means the GUI is pointless.
Let’s also face the reality that for the most part certification is just a check mark during the purchasing phase. The product has to be certified to be purchased for the particular project. After that there is usually no effort to deploy the software in a manner consistent with the posture used during certification. Hopefully compliance with the relevant STIGs will occur. I’m not saying this is right or this is how it is everywhere, but it is certainly what I have generally seen.
I don’t have that much experience working with Labeled Security, but I somehow don’t think that I would want to be creating or modifying complex security relationships from the command line exclusively. Considering the deployment of systems using LSPP are usually air-gapped classified networks, the security concerns around using X are limited.
If your statement “Let’s also face the reality that for the most part certification is just a check mark during the purchasing phase.” is true, then vendors would not spend $500,000.00 or more on getting their products certified under Common Criteria. It is as I said previously, if the OS is not on the NIAP Approved List, it cannot be used, period. For more information I would start with DoD Instruction 8500.2 which can be found here:
http://www.niap-ccevs.org/cc-scheme/
I have worked in multiple environments where IA personnel have stated “If it is not on the NIAP Approved List, forget it” or words to that effect. These are the people who sign off on the security for the command or installation. It is in their best interest that evaluated products be used. Why do you think RedHat and Novell go through this process, because if they don’t Linux would not be in use within DoD at all.
And if you are refering to the DISA UNIX STIG, I wouldn’t bother, since the UNIX STIG (which covers Linux) is essentially a joke. As I am preparing for a DISA inspection and have run the SRR scripts on both Solaris and Linux machines, it seems DISA’s focus is on things like password length, complexity, user account lockout and virus protection. On every UNIX/Linux machine we have run the SRR scripts on we get a CAT I finding for not having an anti-virus scanner on the machine. In other words applying Microsoft “security” solutions to non-Microsoft operating systems.
This is not security, this is “checking the box” in order to make senior management feel better while not doing anything to actually improve security of a DoD *nix asset, what Bruce Schneier calls “security theater”.
Jim Laurent of Sun has a nice blog entry comparing Solaris 10 with Trusted Extensions against RHEL 5:
http://blogs.sun.com/jimlaurent/entry/solaris_trusted_extensions_vs…
Even he brings up the point of no trusted X. For RedHat to seriously see some traction in the space normally occupied by Trusted Solaris it would have to have the same feature set minimally, the RedHat offering simply doesn’t compare.
While achieving the EAL4+ CC certification is good, one has to look past the press releases and dig into the Security Target report to see what was tested and what was not, then make your own judgement as to whether the product meets your needs.
The article you linked to has (in some ways) outright lies. Here is a very nice rebuttal:
http://mentalrootkit.org/?p=16
From the sun comparison:
“RHEL5 LSPP requires customized versions of Linux file systems to associate security contexts with files and requires that the security context be specified for mounted file systems. The file systems are customized by extending the inode to include label information. Because of this strict requirement, new file systems and existing backup software must be specifically modified to support labels in order to work with RHEL5 LSPP.”
He is talking about extended attributes which do *NOT* require “customized version of Linux filesystems”. It just requires filesystems that support EA such as ext3. Many of the claims in that Sun article are outright FUD where many (like trusted X) are very valid. Never trust a comparison that includes sun products from a sun employee. It doesn’t make sense.
Well unfortunately I am going to disagree with you on this one. It is not FUD because it comes from a Sun employee. If a RedHat employee was to post something making claims about RedHat Enterprise Linux and say that RHEL is better than Solaris, that wouldn’t be FUD?
My money is on Sun because let’s face it, they have been at this trusted OS game a lot longer than RedHat has, and while many in the Linux community seem to have major heartburn with Sun (and I really don’t know why, maybe somebody can explain it to me sometime) I think they have a point. If you are looking at a trusted OS, all things have to be taken into consideration. And if RHEL cannot do the same things as Trusted Solaris or Solaris 10 with Trusted Extensions, then RedHat has some work to do! That is not FUD.
We use Trusted Solaris at where I work, and while the group that uses TSOL made it clear that they wanted something else, I somehow don’t think this is it.
This is a step forward for linux in general in this sector. It brings them closer to big UNIX OS in terms of certifiable security (not to be confused with ‘it SHOULD be secure’). I think this will influence a fair few workstation purchases
What interests me in this article is that the author seems almost dismissive of this certification, or at least the testing criteria it targets.
This puts most, if not all, interesting security threats outside of the scope of the testing
Evidently, “military strength” security is only able to resist its own users making mistakes rather than a concerted effort by an enemy
so they are 2.5 years behind
You didn’t read the article. EAL 4+ is a approval level. What got approved is important. In this case that includes LSPP and CAPP which SLES does not include.