Design Article
Linux and Security: Mission Impossible?
Bernard Cole
10/23/2009 12:10 AM EDT
Detractors have maintained that the complexity and architecture of Linux make it unsuitable for high criticality applications. With a lifetime of over 15 years, there are now plenty of public statistics with which to analyze Linux security.
Linux in Government Security Systems
Some powerful organizations have sided with the supporters. Linux is the trusted operating system in HP's NetTop [1], the IBM Trusted Thin Client [2], and the General Dynamics Trusted Virtual Environment (TVE) - a product of NSA's High Assurance Platform (HAP) program [3].
All of these products are designed to consolidate computers used by government personnel to access classified and unclassified networks. The specialized computer provides multiple "virtual" desktops and is trusted to protect sensitive information.
In order to prepare it better it for the task of becoming the "touching point" between physically distinct networks, Linux was enhanced by the NSA's National Information Assurance Research Laboratory with additional security controls, known as Security-Enhanced Linux (SELinux)[4]. The SELinux extensions have been adopted by the Linux community and these systems.
Along with their investment in Linux, these military suppliers have made forceful claims about the trustworthiness of these products. According to General Dynamics, the TVE provides "high robustness" and a "quantum leap in the way military and government security levels are accessed." [5]
It is interesting to note, however, that the NSA's developers were careful not to claim suitability for high criticality systems, stating that SELinux is "very unlikely by itself to meet any interesting definition of secure system."[6] Furthermore, the SELinux effort has included "no work focused upon increasing the assurance of Linux itself." [7]
Vulnerabilities in Linux
While many discussions about the security of Linux have been clouded by hyperbole and commercial agendas, a number of independent resources, many published by the Linux community, are painting a more complete, unbiased picture about Linux security.
In the first release of Linux 2.6 (2.6.0), the Linux kernel consisted of more than 5 million lines of code.10 In 2.6.30, that number has grown to over 11 million lines.[8]
In addition, Linux development follows general commercial practices, not compliant with any stringent safety or security standard. While Linux's open source exposure has enabled it to achieve a low defect rate relative to most commercial software, the size of the kernel assures a large dose of flaws. In 2004, an automated static analysis tool discovered almost 1,000 bugs in the Linux kernel.[9]
NIST and the DHS National Security Cyber Division publish a catalog, the National Vulnerability Database (NVD), of security defects in commercial software products. As of August 16, 2009, a search on Linux yields 1288 entries, 457 of which are considered "High Severity."[10]
134 high severity vulnerabilities are associated with the Linux kernel. The NVD reports 91, 77, and 87 Linux kernel vulnerabilities for each of the years 2006, 2007, and 2008, respectively[11].
It is statistically assured that a similar number will be found in future years, implying that numerous vulnerabilities exist in today's shipping version. These numbers of course do not account for unreported defects.
Some critical software components gain assurance over time. This occurs when the software is relatively simple, changes very little (except perhaps for bug fixes), and is deployed for a long period of time in a variety of environments.
The Linux kernel, however, undergoes continuous modification, including in the field (e.g. over-the-air patching). The latest major version of Linux, 2.6, has changed more rapidly than previous versions and regularly undergoes major modifications to the "stable branch" of the kernel.[12]
As an example, Linux developer Greg Kroah-Hartman reported that the 2.6.24 kernel saw approximately 5,000 lines of code added per day during a three month period, prompting his lament, "It's fricken scarily amazing that things are still working at all"[13]
The rate of change has been accelerating. Kroah-Hartman reported that over 12,000 lines of code were added per day on average during the 2.6.30 development cycle[14]. Since 2005, the Linux kernel has been modified by over 5000 different people [15], at a rate which now exceeds 6 changes per hour.[16]
Another good example was provided by Jim Ready, founder of Linux vendor Montavista, who discussed NVD defect CVE-2006-1528 which was patched in Linux version 2.6.13. In order to get the bug fix in a supported release, a user running 2.6.10 would have been forced to take in 846,233 new lines of code (representing the changes between 2.6.10 and 2.6.13) [17].
On August 10, 2009, a memory leak in the SELinux security extensions was published in the NVD.[18] A few days later, five more vulnerabilities were published.
One of these, CVE-2009-2692, reports a severe kernel defect that can be trivially exploited by a user to take complete control of the system.[19] This vulnerability exists in every Linux operating system deployed over the past eight years.
|
|
|
|
|
EmirO
10/24/2009 1:01 PM EDT
Actually the article is spot on, and we must take care to separate our opinions on Linux from the technical fact that it is a general-purpose operating system that was not designed with security or robustness as a primary requirement. Of course Linus and all contributors work hard to make Linux more secure and more reliable, but if you've never gone through some of the specifications for safety critical (e.g. DO-178B) or robust (e.g. Common Criteria for particular PPs), you can't quite appreciate the difference between a desire for, a best effort towards and a formal proof of these requirements.
Answering the Guest's question of what it takes has been done, but it's worth another article to answer. The fact is that using Linux in an IT environment can indeed add diversity alongside BSD and even Windows, and where Windows PCs protect National secrets I believe (but I can not yet prove) that Linux is a better choice, but to Mr. Cole's point, no way am I getting on an airplane controlled by Linux. I have a hard enough time keeping an Android phone from rebooting and a Linux Web server from crashing.
Smaller, more purposefully designed RTOSs with formally applied methods are still better suited critical tasks. How long that remains true is up to how badly both the RTOS and GPOS camps want to play in each-other's spaces.
Sign in to Reply
SteJav
10/26/2009 3:42 AM EDT
Great article and I agree with the comments made by EmirO. Is QNX certified to any particular security standard?
Sign in to Reply
Pragmatist
10/26/2009 12:52 PM EDT
This article reads like a smear: distorting of the facts subtlety combined with emotionally laden bias.
Just exactly what high capability OS in broad use has NO CVE reports? Who would be irresponsible enough to incorporate a software product without waiting for a normal upstream maturation for issues related to security, reliability, and performance (latency, throughput, scalability)? When would an embedded product be developed without identifying the specific nature of the hardware, characterization of I/O, and constraining to required capabilities?
Even in the case of more general purpose computing application in secure contexts there are input and networking constraints; physical access constraints; and possibly even the need to operate in a Faraday cage. Furthermore, maturity of an upstream source (say RHEL5 a _minimum_ of 18 months after release) combined with meticulous tracking of security issues; rapid incorporation or mitigation for solutions; custom high constraint security profiles (SELinux, standard security; constrained daemons; auditing; ACLs; etc.).
If my solution includes Linux in a embedded secure context I get the benefit of its extensive exposure to insane hardware configures; naive users; remote cracker hackers; complex daemon configurations; heavy loads; etc. These use cases provide focus for developing of constraints and system maturation which few solutions can match. Furthermore, I can look at tools like Coverity for doing my own security auditing.
None of the other RTOS solutions can make these claims since none of them have the level of resources and real world auditing to which Linux is exposed. OpenBSD can make some pretty good security claims due to the attention paid to auditing early in the process, but I don't see the proprietary commercial solutions matching the benefits of either one.
If someone discovers a bug in an X server I don't use (and doesn't exist on a competitive platform) when used in conjunction with a NIC driver I don't use (and also doesn't exist in the competition) along with a print driver solution that I don't use and a security configuration I don't use with a filesystem type that I don't use and kernel options that I don't use: should I consider the comparatively limited proprietary solutions to be superior or irrelevant?
Sign in to Reply
davek_ghs
10/26/2009 3:51 PM EDT
INTEGRITY is the market leading (revenue market share) high reliability RTOS technology, deployed for more than a decade in life-critical medical devices, aircraft control systems, industry/process control systems, NSA-approved crypto communications equipment, printers, networking gear, web servers, automobiles, etc. Many of these devices are network-connected and must protect against the most sophisticated attackers (not your run-of-the-mill Internet script kiddie).
This technology has also been certified to the highest levels of safety (DO-178B Level A) as well as the highest Common Criteria security level (EAL 6+/High Robustness) ever achieved for any software product. This level requires, among other things, a formal mathematical proof of system security. While Linux is great for many things, high robustness security was simply not a goal of its designers.
But theres no reason why the security of INTEGRITY and the bells and whistles of Linux (and other general purpose platforms Android, Windows, etc.) cannot coexist. INTEGRITY first hosted Linux in virtual machines within hand-held mobile devices back in 2003. And over the years, that model has extended to PCs and smartbooks, networking equipment, and many other types of embedded and mobile devices with many different guest operating systems. So we can have the best of both worlds bullet proof security alongside our favorite multimedia environments. Surf the web with Firefox or Chrome while INTEGRITY guarantees the authenticity of your financial transactions. INTEGRITYs security design and modern CPU architecture have made this practical. So lets get beyond the argument of how secure Linux is and apply best of breed technology in harmony to truly unlock the potential of our digital world.
Sign in to Reply
Longpoke
10/31/2009 7:10 PM EDT
The reason why General Purpose O/S are insecure isn't that complicated, Using C or low level languages alike is just fundamentally insecure (unless you are God).
If you want to see General Purpose O/S become secure, the entire paradigm which they lay upon will have to shift. I hate to admit it, but things like Java CPU would have to become mainstream, and even then, there is still the possibility of semantic flaws in code. Then after all that, you have to be able to trust 1) your O/S vendor, 2) your software vendors, 3) your hardware vendors. This is why I agree with the article.
I don't think truly secure GPOS will be possible until significant fundamental changes are made. I can see it becoming impossible for stack smashing bugs to happen, but vendor trust, how would that ever happen? Thousands of people work on systems such as Windows, *Nix, and *BSD. I'm sure a little evil code slips in every now and then.
Sign in to Reply
GordonScott
8/30/2011 6:26 AM EDT
Any large-scale GPOS must almost by definition contain too much code to be fault and vulnarability free.
Add to that that the main GPOSs today have their foundation in the PC market, where new hardware appears about every waking hour, for much of which new software support is needed, and it's clear to me that these OSs are at best fundamentally challenged in even their _chance_ of meeting high security needs. And that applies to Linux, the BSDs, Windows and almost certainly some of the less popular/prevalent OSs.
The situation is better where these OSs are cut-down embedded implementations, but even there, the pace of change is concerning, possibly alarming.
IMHO, putting "GPOS" and "High Security" in the same sentence is an oxymoron.
Sign in to Reply