AMTU 1.07 has just been released on ATMU’s Sourceforge home. This release incorporates a patch from Joy Latten to add IPv6 interfaces to the list of interfaces probed to test networking devices. It also contains a small fix to the memory separation routine.
MD5SUM: 8858a47c667ffc4af840d72d8ced6605 amtu-1.0.7.tar.gz
SHA1SUM: 7f56a17ca616b6dc23564894c8503e5c5c75aa06 amtu-1.0.7.tar.gz
amtu is a small and simple machine check that is required for Common Criteria certification. It was originally released in 2003. You can find it at https://sourceforge.net/projects/amtueal/.
LinuxSecurity.com is running a fascinating retrospective on the Top 10 SELinux stories of 2007. It makes for fascinating reading and shows some of the issues around SELinux (complexity – #1 and #8), some of the progress that was made in 2007 (secure networking – #4, setools – #6), and some of the critical benefits of using SELinux (SELinux protection of Samba – #2 and #10). The top stories were chosen based on the number of hits they generated. I think that it is too bad that a story about a wiki (#3) beat out any story on the first Common Criteria certification of SELinux (not present on the list at all). The importance of the Common Criteria certification of SELinux in RHEL 5 is that it makes it more easily adoptable by the U.S. government which in turn makes Linux in general more easily adoptable by the government.
http://www.linuxsecurity.com/
http://www.linuxsecurity.com/content/view/133305/169/
The NSA has published their Guide to the Secure Configuration of Red Hat Enterprise Linux 5[1]. This is an excellent document that describes best practices for securing a Linux system – tailored to Red Hat Enterprise Linux 5. It starts with best practices, such as, encrypt transmitted data and minimize installed software. It then follows up with exact configuration recommendations, for example, the exact configuration option to prevent root from logging in directly via ssh (Section 3.5.2.6). They do a pretty good job describing the rationale for making the changes that they recommend (“The root user should never be allowed to login directly over a network, as this both reduces auditable information about who ran privileged commands on the system and allows direct attack attempts on root’s password.”). If you are responsible for the security of any Linux system (whether as a developer or an administrator), I highly recommend taking a look at this document and thinking twice about any decision that you make that runs counter to these recommendations.
[1] http://www.nsa.gov/snac/downloads_redhat.cfm?MenuID=scg10.3.1.1
EDIT 4/21/2009: updated a corruption that rendered the ‘ in the word root’s incorrect
The new location for the guide is http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
According to HP Backs Red Hat in Government Biz Bid [1], “Lillestolen said, however, that HP has gone further than Big Blue by certifying a wider range of hardware.” Hopefully, this is just a mistake in the reporting and HP isn’t actually making such outrageous claims. As you can see in the Validation Report [2], HP tested on
- Intel Xeon (HP DL360)
- Intel Xeon/Pentium (HP Compaq dc7600)
- Intel Xeon EM64T (HP DL360) – dualcore
- Intel Xeon EM64T (HP DL360) – singlecore
- AMD Opteron (HP DL 385) – singlecore
- AMD Opteron (HP DL 385) – dualcore
- AMD Opteron (HP DL 145) – singlecore
- Intel Itanium 2 (rx 3600) – dualcore
- Intel Itanium 2 (rx 2620) – singlecore
According to IBM’s Validation Report [3], the following platforms were tested:
- System z Hardware: z900/z9 Host Operating system running: z/VM 5.1 or z/VM 5.3 within a PR/SM logical partition
- Opteron Hardware: model 3455, Bladecenter LS-21
- System p Hardware: p5 720 (9124), Bladecenter JS-21 Host system running: LPAR partition
- System x 3550, HS-20 Bladecenter, HS-21 Bladecenter Hardware: Intel Xeon with Hyperthreading and EM64T
In both cases, 8 different machines were tested. However, IBM tested radically different architectures, whereas HP tested minor variations of a few themes. For those of you not familiar with IBM terminology, the IBM evaluation tested a mainframe, a POWER system, a POWER blade, a rack-mounted Opteron system and Opteron blade, two Intel Xeon blades, and a rack mounted, dual-core Intel Xeon server. For those unfamiliar with HP’s line of hardware as I am, their website shows that HP tested one desktop and 3 rack-mountable Intel Xeon systems, three rack-mountable Opteron systems, and two rack-mountable Itanium systems. None of the systems listed in their Validation Report is a laptop contrary to Lillestolen’s claim.
I am glad to see that RHEL5 has received so much testing in the MLS configuration. Perhaps widespread knowledge that many systems were tested in many configurations will help speed the adoption of the MLS configuration in the defense industry. But I hope that reporters won’t let HP get away with making such wild statements that are easily refutable via on-line documents.
[1] http://www.internetnews.com/ent-news/article.php/3708611
[2] http://www.commoncriteriaportal.org/public/files/epfiles/st_vid10165-vr.pdf
[3] http://www.commoncriteriaportal.org/public/files/epfiles/st_vid10125-vr.pdf
As a security practitioner, you’ve got to love it when your company comes out with a line like “Security is our brand” [1] and the press eats it up. Of course, security has always been our brand and, on the Open Source side, we have done some significant things to prove it. I’m speaking here of our multi-million dollar investment over the course of many years to Common Criteria certify Red Hat and Novell SUSE. We started out at EAL2 with the security functionality defined in our Security Target against the pre-existing security functionality in SLES 8. We got that evaluation done within 6 months when everybody was saying that it couldn’t be done – ‘Common Criteria certification takes years’, ‘open source can’t be certified’ they said. From that ground work, we marched up the value chain to LSPP/RBACPP/CAPP at EAL4+ with RHEL5 when still (after 6 successful evaluations at progressive levels) people were saying that it couldn’t be done (although much more subtly now) – “The lack of this protection might prevent another evaluation target from passing this evaluation.” [2]
Our LSPP evaluation included more hardware platforms in one evaluation (7) than all previous completed LSPP certifications combined. The beauty of the range of platforms certified is that it allows government agencies who need LSPP to also take advantage of the scale-up and scale-out capabilities inherent in Linux. As a tax payer, I love this because it allows government agencies to benefit from the lower TCO that Linux and open source software provide.
The LSPP evaluation, in my eyes, constitutes a revalidation of the open source development methodology because the project included competing and cooperating companies, along with government, distro, and individual contributors who were contributing as a labor of love and because they believe in the necessity of adding this level of security to Linux.
When we completed the LSPP evaluation, I went back and looked at all of the people who had contributed to the Common Criteria certification effort over the years. Just within IBM, the number went into the high double digits. Of course, none of this would have been possible without the dedication and passion for security shown by Novell and Red Hat. And our evaluator was invaluable – the insight, integrity and sheer brilliance of the people working for atsec is without measure or compare.
Security is Our Brand!
[1] http://www.internetnews.com/security/article.php/3708446
[2] http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts.jsp
It is amazing to me to see such ignorance about Common Criteria displayed in an article in a magazine targeted to the very government agencies that require it. Common Criteria has loads of critics, but is it getting a bum rap? In the print version, the comment “You are not testing the product at all. You are testing the paperwork.” is called out prominently with the picture of the person who allegedly said it. All levels of Common Criteria require functional verification of the security features and EAL3 and higher require both positive and negative testing of the security controls. You can see the thousands of tests that were used for the recent certification of Red Hat Enterprise Linux 5 at the LTP download site: RHEL5 LSPP Tests. That is just the most egregious comment in the article. Far more reasonable is the claim, “The evidence so far suggests that it is a waste of time and resources.”
I do feel the tug of this argument and agree with it to a limited degree. The intangible value of Common Criteria is that products evaluated at the same level against the same protection profile are within a reasonable degree of security functionality. This means that the purchaser doesn’t have to do all of the due diligence work themselves, if (and only if) the security functionality that they need is included in the protection profile. The most common criticism of Common Criteria is that the level of security functionality that most people need is not in any commonly used protection profile.
A little more tangible are the bugs found and fixed during the Common Criteria evaluations. Several kernel bugs and PAM bugs were fixed during the course of the Linux evaluations. I am glad that those bugs have been found and fixed. The small number of bugs in this category validate the open source methodology and the high quality of the Linux codebase. I don’t believe that the handful of bugs in this category justifies the high cost of Common Criteria certification.
Most tangible are the new security features that have been adopted and are now seeing widespread use. The audit subsystem was created primarily in response to Common Criteria requirements. There was resistance to adopting an audit subsystem until the requirement was made clear by the call for Common Criteria (along with other enterprise customers). The LSPP evaluation brought in labeled networking, polyinstantiation and other security features that might still be languishing if not for the evaluation requirements. As these features become more widely understood, they will see more widespread usage.
Adding together these three types of tangible and intangible benefits, I do believe that the Common Criteria evaluations of Linux have been worth their cost.
Another part of the article that made me scream with pain (and why):
“One of the reasons for the focus on the process rather than the code is that the evaluation process is intended for proprietary code, which developers generally keep secret.” The evaluation labs have full access to the code that they are evaluating whether it be proprietary or open code.
A reasonable point:
“…disconnect between industry and NIAP has resulted in an awkward evaluation process that ensures that security products are well into their life cycles, if not obsolete, by the time they can be evaluated…” It has taken most vendors a long time to complete evaluations and it is a difficult proposition to balance starting the evaluation before the product is completed with the time to finish the evaluation after the product has been made available. Microsoft took 3 years to complete their evaluation of W2K. But the evaluation of Red Hat Enterprise Linux 5 at EAL4+ completed only about 3 months after RHEL5 was made available.
And some very good points:
“Under the scheme, everyone accepts one lab’s results … results cannot be easily confirmed.”
“… there is no feedback loop for measuring and refining the Common Criteria process.” NIAP did poll companies who had completed Common Criteria evaluations a year or so ago, but it is hard to see any impact that the comments may have had.
Only one person interviewed for the article had actually taken a product through evaluation and he didn’t really have much to say. The article would have been stronger and more accurate if they had pulled in more participants, but it was certainly entertaining and engaging as written.
