Is Linux Secure?
Consider the amount of attention paid to proprietary code versus the many eyes upon the code for an open source operating system.
It is a legitimate question to ask whether an open source operating system can be truly secure. After all, it’s out there for both white and black hats to find and fix or exploit vulnerabilities. However, the short answer is “yes,” a Linux distribution can be secure, and in general it can be more secure than a proprietary OS. The open source Linux kernel has been in a perpetual state of development for over 20 years now, with a “stable” version that is used by most (usually after it has been out for a year or so) and the most recent version (more like a “beta”) that sometimes enables the latest technology for products on the leading edge of the early-adoption wave. Linux is successfully used in the U.S. Postal Service, on Amazon and Google servers, at IBM and in the New York Stock Exchange trading platform, CERN’s Large Hadron Collider, nuclear power plants, entire train systems, the U.S. Department of Defense, the U.S. Navy submarine fleet, and the U.S. Federal Aviation Administration.
The number one most obvious reason why Linux can be secure derives from some common sense: every line of code is viewed multiple times and subject to approval. Anyone can inspect the code before adoption. Problems are spotted and reported rapidly, and code is updated much more often than proprietary code (in general). Proprietary code gets much less attention to detail, and whereas it is possible for a disgruntled employee to integrate malicious code without the notice of his peers, Linux is always inspected and re-inspected as thousands of developers work towards the next build. All software is vulnerable to hackers, however, regardless of origin. But it is a fact that Linux has the participation of some of the best security experts in the industry, and benefit of thousands of years’ worth of software development experience in multiple industries resides within the caretakers of Linux.
Other than the above, there are security measures that can be implemented with any OS. Security-Enhanced Linux (SELinux) is one example and began over a decade ago as a project of the U.S. National Security Agency (NSA). SELinux incorporates mechanisms for security at the kernel level. One mechanism is Mandatory Access Control (MAC). SELinux is not a firewall. (A firewall controls flow to/from a network.) SELinux includes, but is certainly not limited to, mechanisms such as buffer overflow protection, memory checks, type-bounding, expanded execstack controls for thread control, user-space tools, and of course processes (e.g., plug-ins) are confined to specific ports, are only allowed to write in specific areas, and cannot mine data from sensitive areas. This is a partial list of security measures that can be implemented with SELinux.
Automotive Grade Linux
Another distribution with security baked-in at the kernel level is Automotive Grade Linux (AGL). Besides the usual strategies of encryption and digital certification for boot images, AGL practices a type of MAC called Role-Based Access Control (RBAC), which is built into the Linux kernel, where the OS denies an application’s system access to certain areas based on a “need to know basis.” Flexibility and usability suffer for the sake of security, but most would agree that enforcing a safe car at the sacrifice of free screen savers is worth it. For example, what if a car owner could buy a “software appliance” that enables the user to plug in a USB stick that loads an app to the car so they can see real-time engine diagnostics on the dashboard touchscreen and calibrate controls to customize car performance. This kind of customization would be terrific for the user, but a nightmare for automotive safety. With Role Based Access Control in AGL, if media entering through the USB port carries a successful virus, it remains confined to the Infotainment system because the USB port is not able to access anything other than a media player. A program entering through the USB port would never be able to initiate anything beyond perhaps reading diagnostics to the touchscreen, if that. A virus will not reach the instrument cluster or an ADAS component, however, because it does not have the keys to enter any other domain.
As an open kernel, Linux has the benefit of many eyes inspecting it. This slows development somewhat, but you are far less likely to have corner cases as in proprietary operating systems where a disgruntled employee might be able to insert code that goes unnoticed.
Security will always be challenged with new angles for being compromised as code accommodates new technologies. Locking down access is one method for managing security. In the end, security is constantly in conflict with an unfettered, one-size-fits-all user experience. Certain user actions will never be supported without risk (e.g., installing random or legitimate but poorly written plugins).
- “FAQ.” SELinux Wiki. 16 Oct 2009, 13:56 UTC. 12 Oct 2016, 03:00 https://selinuxproject.org/w/?title=FAQ&oldid=729.
- “Linux Security Summit Videos.” August 2016. 12 Oct 2016. https://www.linux.com/news/linux-security-summit-videos
- March 23, 2010 http://www.comparebusinessproducts.com/fyi/50-places-linux-running-you-might-not-expect
Lynnette Reese is Executive Editor, Embedded Systems Engineering and Embedded Intel Solutions, and has been working in various roles as an electrical engineer for over two decades. She is interested in open source software and hardware, the maker movement, and in increasing the number of women working in STEM so she has a greater chance of talking about something other than football at the water cooler.