Compliance kinks
Although governments at all levels are widely adopting Linux, it still faces challenges; one, especially at the federal level, is that Linux doesn't comply with several standards. The problem is particularly acute because government agencies are notorious for setting hard and fast procurement policies and sticking with them, even when they rule out more capable, cheaper products.
For example, many nations, including the US, Canada, and most European countries, have agreed on a set of common criteria for evaluating information security. Those nations evaluate products against the Common Criteria Evaluation (CCE) and rate them accordingly. All the countries have agreed to accept another country's CCE of a piece of software. Unfortunately, the CCE requires some security features that Linux doesn't have. While Linux is hardly insecure, it was designed using the Unix-in-the-university model and lacks some features considered vital by the Common Criteria process.
"Linux does not have strong user accountability built into it," said Dr. Tom Haigh, chief technical officer for Secure Computing, a San Jose, Calif., firm that specializes in secure operating systems. "It is not up to the standards in the protection profiles."
Secure Computing is building a secure version of Linux for the National Security Agency using type enforcement, which is, according to Haigh, a proprietary technology that labels processes and data objects and allows applications to access only appropriately labeled items. Haigh said type enforcement is different from the standard Unix and Linux "discrete" security model, in which access to processes and data is determined by the user's security privileges. For example, a process is denied any improper access to a data object, regardless of what user is running the process. Thus, the danger of security problems resulting from user error drops. "The object is to put in place a mandatory mechanism to force security policies to maintain the integrity of applications," said Haigh.
Secure Computing intends to release as open source the kernel modifications and basic policy engine for type-enforced Linux, although the company will keep its own policy engines proprietary.
Haigh said Secure Computing is not attempting to produce a version of Linux that will meet the CCE's standards, although the type-protected Linux should be extremely secure. Developing a version of Linux that meets the Common Criteria probably would not take much work. But so far, Haigh said, no one has done it.
The practical effect of not being Common-Criteria-compliant is an open question, Haigh said. "CCE is just starting to take off now. A significant number of products have not been through evaluation. At this time it's probably fair to say there's not a lot of significance." However, he said, this is likely to change over the next several years. "The US DOD has already said for some sorts of products, firewalls particularly, they will require CCE in the next year or two," Haigh said. "As requirements like that become more common, it could become quite significant."
Linux's Posix compliance presents a more peculiar question. While Linux is generally considered Posix-compliant, it doesn't meet all the latest Posix requirements.
According to Marty Wesley, enterprise product manager for Red Hat, the problem is that Posix compliance is a moving target; the Posix standard has been altered over the years. There are now two major parts of the Posix standard, Posix.1 and Posix.2 -- also known by their IEEE standards names, 1003.1 and 1003.2. Each is subdivided into parts that deal with different issues, labeled 1a, 1b, and so on. Posix.2 supplements, rather than replaces, Posix.1.
Although Posix compliance was desired in Linux's early days, Linux was always compliant only at a very basic level (like Windows NT). Part of the reason for that was Linus Torvalds's decision that Linux wouldn't even try to meet Posix requirements that were obviously dumb. Between the original decisions and the advances in Posix, the Linux kernel currently doesn't meet the Posix standards for a number of features, Wesley said. Those features include the regular expression matcher, global semaphores, global conditional variables, and message queues. There have also been recent extensions to the Posix thread requirements related to multithreading, in the areas of signal handling and getpid.
"In all, it's about 90 percent there," Wesley said. "[Meeting] the rest of them would require some work but [our people] don't think it would be an extreme amount." In fact, a number of people have contributed patches to make some additional features of Linux Posix-compliant. (See Resources for links to those patches.)
Unlike the Common Criteria situation, the lack of full Posix compliance already affects federal agencies' adoption of Linux, particularly in the Department of Defense (DOD), which has established a Defense Information Infrastructure (DII) as a roadmap for its IT future. The DII is built around Linux, but because Linux isn't fully Posix-compliant, the DOD often doesn't use Linux for DII applications.
Finally, Wesley said there are some standards Linux can never meet. The classic example is ISO 9000, which certifies the way products are developed and produced, rather than the products' characteristics. "ISO 9000 pertains to the processes around the development of the product," Wesley said. "With open source development, there's no way to meet it."
That is a problem because government and industry are increasingly accepting certification under the ISO 9000 family of standards as a hallmark of quality. In fact, it is no such thing. ISO 9000, and related standards like 9001 and 9002, guarantee that the process will be well documented, but not that the product will be any good. The Firestone tire factories that churned out millions of defective tires displayed signboards proclaiming they were ISO-9000-certified. Less extreme examples abound.
That probably means that over the next couple of years, the Linux community will have to develop distributions of Linux that meet those standards. That will require Linux developers to do a good deal of work, but Linux's modular structure will make it a lot easier. And it'll mean the rest of us won't have to worry about whether Linux is compliant.
Print
Close Window