As secure Linux goes mainstream, Common Criteria becomes an issue

IBM Corp. plans to seek Common Criteria certification this year for Security Enhanced Linux, marking the first such evaluation for this module of the open-source operating system.It is not a trivial undertaking, said K.S. “Doc” Shankar, security lead at the IBM Linux Technology Center.The Common Criteria unfortunately are written with proprietary products in mind, Shankar said recently at the first SELinux Symposium in Silver Spring, Md. “There has been considerable skepticism whether open-source code could ever be certified.”Both IBM and Hewlett-Packard Co. have succeeded in getting flavors of Linux evaluated under the Common Criteria’s Controlled Access Protection Profile. Shankar said IBM hopes to submit SELinux for evaluation under the Labeled Security Protection Profile this summer. He expects the process to take about a year.“There is a lot of work to do,” he said. “It’s going to be a challenge.”The Common Criteria are standards for evaluating security software against vendor claims or user requirements, called protection profiles. Evaluation is done by ap- proved private laboratories and is recognized by multiple nations. The program is overseen in the United States by National Information Assurance Partnership, a collaboration between the National Institute of Standards and Technology and the National Security Agency.The difficulty in shepherding SELinux through the Common Criteria is ironic. It was NSA that developed and released the secure operating system.SELinux is the product of 12 years of work by NSA. Its distinguishing feature is mandatory access control, in which each process runs in its own “sandbox” with limited permissions, preventing or mitigating abuses.“Ultimately, secure systems depend on having a secure operating system,” said Stephen D. Smalley, a lead SELinux developer in NSA’s Information Assurance Research Group. “Mandatory access control is a key feature missing in most operating systems.”SELinux is an application of NSA’s Flux Advanced Security Kernel. The open-source Linux operating system was chosen for the mainstream transfer of FLASK, which was incorporated into the Linux kernel in 1999. It was released as a reference implementation in December 2000, and in 2003 SELinux was adopted into the Linux 2.6 kernel.The mainstreaming of SELinux is part of the agency’s shift from proprietary, government-only technology to off-the-shelf products, said Dickie George, technical director of the Information Assurance Directorate.“Thirty years ago, we built everything we needed to use,” George said. “The game has changed. There is no way on Earth we can provide everything that is needed.”Rather than keep its technology secret, the directorate wants to see it mainstreamed into commercial products.Although SELinux is being incorporated into commercial distributions, such as Red Hat Enterprise Linux 4, it is far from a finished product. Attendees at the symposium came to hear about work to create applications for SELinux and to extend the operating system’s mandatory access controls onto the network.Red Hat Inc. of Raleigh, N.C., is creating tools to handle requests to applications running under SELinux, limiting the access of applications and mitigating flaws in the software. Because of the complex lines of interaction between applications, “there is a lot of engineering to do,” said Colin Walters, a developer at Red Hat.Widespread adoption of the operating system eventually will require Common Criteria evaluation, and no one is satisfied with that process, not even NSA.“We want to take that in a new direction,” George said. “We waste a lot of time and money on testing that really isn’t buying us anything.”The focus of Common Criteria evaluation is on the documentation and development process rather than the code itself, George said. This was necessary when the criteria were developed, but the focus should move now to software assurance.“NIAP testing should imply that this code has some level of goodness to it,” he said. “That’s not the case today.”The problems are amplified when evaluating software developed in an open-source community rather than a proprietary environment. Documenting the communal process is much more difficult, Shankar said.“It’s very labor intensive” to produce and verify the documentation, he said. “I don’t like Common Criteria.”Updating the standards to accommodate open-source code “is something that needs to be done badly,” he said.