By now, most people in the Linux world have heard of Security Enhanced Linux (SELinux). Since its initial release...
by the National Security Agency in 1999, SELinux has become a standard part of the Linux kernel and a supported capability in many Linux distributions including Red Hat Enterprise Linux 4 and 5.
What you may not realize is all the ways SELinux is being applied to a variety of security challenges. Just because SELinux was initially developed by the military does not mean it is only useful to complicated security problems and large-budget organizations – SELinux is for you too. And despite what you might have heard, you don't need to be an expert to reap the benefits of SELinux's powerful protection features.
- Look mom, no policy compiler
Perhaps the most common statement I hear about SELinux is something along the lines of "well it's really great security technology but isn't it too hard for the average user to use?" That's like saying the Linux kernel is great operating system technology but my mother can't figure out how to write a device driver. Ordinary users can use SELinux just fine; indeed, you might be using it now and not even realize it. Let me explain.
One of the key traits of SELinux is that it provides comprehensive mandatory access control (MAC) that is both flexible and configurable. What makes it configurable is a rich and sophisticated policy language that allows a developer to control just about any resource provided by the Linux kernel. Since the kernel is rich and complex, SELinux must provide a rich policy language to allow us to control potentially any resource.
This is sophisticated stuff and should make you feel rather good that it is readily available to all those ordinary users out there. Now, if those users had to write all the policy rules to secure a Linux system, then that would indeed be too hard to use. However, just as they don't have to break out the C compiler and start writing code to manage memory segments and task descriptors to use the Linux kernel, users don't have to write policies to get the benefits of SELinux. All SELinux distributions provide base policies that give their users the benefits of SELinux MAC security. For example, RHEL 5 has a SELinux policy that provides enhanced security protection for hundreds of services and applications. You don't have to do anything -- it's just there. How easy is that?
Of course, if you want to customize the policy or gain even greater security, you can with tools ranging from the new setroubleshoot tool to a variety of more sophisticated technologies (read on). Editor's note: SELinux Troubleshooter (also known as settroubleshoot) is a new tool in RHEL 5 that watches the audit log files for AVC messages. When an AVC messages arrives, the tool runs through the SELinux plugins database looking for a match and then sends a message to the user with a description and a suggested fix.
- SELinux -- not just for governments anymore
I mentioned that SELinux provides flexible and configurable MAC security. Now, if you've heard anything about MAC, it was probably that it is something that the military or perhaps large banks with lots of money might use. Well, that's the old MAC. I'm here to tell you that the new MAC à la SELinux is for ordinary businesses.
Remember I said SELinux provides flexible MAC security. Without going into all the history, let's just say that the open source security community has learned a lot in 30+ years, and the kind of MAC provided in SELinux (called type enforcement) is highly adaptable to many security problems. Let me illustrate by example.
A while ago, a colleague at IBM challenged me to help demonstrate that SELinux and type enforcement is broadly applicable to general-purpose enterprise users. As a result of that challenge, IBM and Tresys Technology, my employer, started an effort to develop a MAC security enhancement for a general-purpose enterprise application. We chose IBM WebSphere, a large and sophisticated n-tier Web application product. A typical WebSphere application would have many networked systems dedicated to a single purpose (Web server, application server, deployment manager, etc.). Our challenge was to provide a security-hardened enhancement for WebSphere applications that was highly customizable to individual sites but required no SELinux knowledge to use and configure. Oh, and the result had to work across many cooperating networked systems.
In the end, we met all of our goals with a SELinux-based security enhancement add-on for WebSphere. We successfully piloted the solution in a U.K. e-commence application and are now extending the solution to include IBM DB2 servers. Application administrators can configure SELinux security simply by providing the network topology and application installation information they must already provide for WebSphere.
This is cool stuff – you get general-purpose, configurable enterprise application MAC security with no SELinux expertise required. WebSphere and DB2 enterprise users can now use the same type of security that sensitive government applications use. Definitely not the MAC we struggled with in previous decades.
- Sand, firewalls and fortresses
A colleague of mine once elegantly articulated a phenomenon that is still common today: We tend to build sophisticated security solutions and applications on top of network and operating system technology that is weak and vulnerable. So while the application may have good security functionality, the overall system (and hence the application) remains vulnerable to attacks to its underlying infrastructure (Trojans, viruses, privilege escalation, etc.). She called this phenomenon "fortresses built upon sand." The strongest castle walls are useless if they are undermined by the foundation upon which they sit.
One of the primary goals of SELinux and type enforcement was to address this "fortress upon sand" problem by providing the means to strengthen the application security foundations in Linux. With SELinux, you can build sandboxes around individual applications and ensure that vulnerabilities and bugs in one application do not interfere with other applications (e.g., no privilege escalation attacks). Indeed, the default policies in distributions like RHEL 5 do exactly that, among other things.
SELinux also brings network protection inside the box. Today, firewalls typically determine the type of network access that processes (any process, as far as the firewall is concerned) inside the system may access. With SELinux we can specify network access that individual processes may access (i.e., "firewalls for processes"). Default policies make limited use of this capability, but any custom policy development can exploit this feature to create exceptionally strong network security architectures. For example, we can limit the Apache process -- and not just the entire Web server system -- to access only specific applications on a back-end server using specific network interfaces and ports. Further, on the application server we can do the reverse and allow the Web application process -- and not the entire application system -- to only access the Apache process on the front-end sever. Now we have the ability to control network access between two processes on two different machines, thereby removing other applications on those systems as attack vectors. (This is, in fact, what we did in the WebSphere work.)
I expect you'll see more and more administrator-friendly tools emerge to allow greater process-level network access without custom policy development.
- But, still, for governments (and banks, utilities, and …)
Although I argued that MAC security as provided by SELinux is not just for government, let me clearly state that it remains an excellent security technology for those sensitive government and business applications that require high-end security. There are many, many ongoing developments that are using SELinux for highly sensitive applications. Indeed, that is what is truly remarkable about SELinux: The same software mechanism can address security problems from the most basic to the most advanced.
Most applications of this type require and demand stricter security policies beyond what comes out of the box, even though they still use the same software kernel; no software changes or special versions are required. There is a lot of ongoing innovation in SELinux tools and capabilities to help with advanced policy development. First, the way policy source is organized and structured has been completely re-invented to ease development (the so-called reference policy. Also a loadable policy module infrastructure now exists to help manage the installation of policy modules. Both of these improvements are fully integrated into current Linux distributions, including RHEL 5. Development tools are also rapidly evolving to aide in writing custom SELinux policy, in particular SLIDE, an eclipse-based IDE for SELinux policy development, and policy generation tools that help auto-generate policy based on profiling.
- Planes, trains and automobiles (and phones and toasters, too)
Product and application developers in the embedded market are also seeing the value of SELinux. Besides traditional security concerns about preventing attacks, SELinux is being used to increase robustness and reliability, protect data and software integrity and to isolate proprietary algorithms and software in embedded devices. This use of SELinux might be the most beneficial to everyone. I don't know about you, but I would like the code controlling my antilock brakes to be protected from bugs in its diagnostic software!
More help on SELinux SELinux Policy Editor: Removing micromanagement from administrative control
Altering security attributes under SELinux
Most embedded-Linux companies have expressed their intent to support SELinux in their distributions. From radios to cell phones to DVRs, you will be hearing more and more about how SELinux is providing enhanced security, integrity and reliability features in embedded systems.
Fortunately, the experience we gained in developing SELinux-based applications over the past five years is now ready to help with the embedded systems market. SLIDE, policy generation tools and policy analysis tools are being packaged and updated to allow even greater use of the powerful security features of SELinux. All of these applications still use the same software kernel mechanism -- remember SELinux has flexible MAC. Special kernel software is not required for each application.
I expect you see SELinux becoming a critical component of protecting over everyday lives in the near future, and you won't even know it.
Frank Mayer is the president and CTO of Tresys Technology, a Columbia, Md.-based Linux security technology vendor. He is also the author of SELinux by Example.