SELinux prepares you for tomorrow's threats, but to reap its rewards you have to understand the MAC security model.

There is a lot of (mostly uninformed) buzz around SELinux (Security Enhanced Linux); it is touted as doing all kinds of wonderful things that it probably doesn't do. It's not a good idea to leap into implementing a complex security application like SELinux without understanding what it's for and how it works, so we're going to start with the basics. Then we'll look at how to use it, and actually understand what we're doing.

Mission Possible

SELinux began as a research project by the NSA (National Security Administration). The old model of reacting only to known threats has a glaring, obvious weakness: You're going to get beat up a lot. The idea behind SELinux is to protect a system from the unknown, and to close the door on zero-day exploits.

It is not designed to correct flaws in Linux; its job is to confine processes as narrowly as possible, even superuser processes, without impairing functionality. It does this by enforcing Mandatory Access Controls (MAC). The traditional Unix system of permissions and ownership is called Discretionary Access Controls (DAC). DAC has long served Unix well, and has the virtue of being easy to understand and use. But it allows users to set unsafe permissions on files that they own, and the superuser is not limited in any way. So one tactic of attackers is to exploit weaknesses such as buffer overflows or unvalidated database inputs to escalate to root. Once they have root, it's all over.

Another weakness of DAC is any application that a user can run has the same privileges and access as that user. This means that any remote application you run, such as a Web browser or mail client, has full access to everything that you do, including your personal data files. This is why services that require root permissions, such as networking services, drop to a special unprivileged user as soon as they can. In the olden days services that ran full-time with root privileges were popular avenues of attack. And that is why you should not dump all of your services into the "nobody" user, because that exposes all of those services to a single successful intrusion. Each service should have its own un-shared un-privileged user.

But in these modern times it's not necessary to gain root privileges to commit nefarious deeds, yet the primary purpose of most security schemes is still to protect root. Users are considered dispensable, like the red-shirted crewmen on the original Star Trek series. As soon as a guy in a red shirt appeared, you knew he was going to be toast before the second commercial break. Think about it—what's the most important stuff on your computer? The system files? You can easily replace those. An attacker might still want to acquire root privileges so they can replace key system binaries to try to cover their tracks. But the system files themselves are not valuable. The valuable stuff sits in your home and other data directories. If you're storing sensitive data of any kind, such as databases full of customer data, that's what an attacker wants.

Another contemporary reason to break into your system is to use it as a spam forwarder. An attacker won't need root privileges for that. Easily compromised Windows computers comprise the majority of the millions of machines that have been conscripted into the World Wide Botnet. But Linux is not immune. There is big money in spam; it is powered by organized crime because it's the first link in the chain to identity theft, DDoS extortion, and other forms of fraud. There's big money in them thar spams, so remote attacks are becoming sophisticated and difficult to combat, unlike the olden days when unlettered script kiddies passed around homegrown Windows viruses for the fun of it.

SELinux Policies

An SELinux policy has no concept of an all-powerful superuser, but only what is allowed and what is not allowed. It takes away the destructive potential of root. A successful intrusion will be confined to the process that it compromises, and will not be able to escalate beyond it. Sounds a bit like a chroot jail, doesn't it? Except that a chroot is not a security device, and was never intended to be one, even though it is commonly taught that it is a security device. chroot is for separating services, nothing more, so that multiple services or users can share the same system without tripping over each other too much. For example you could run multiple separate instances of an HTTP server, or safely sandbox a number of development environments.

SELinux uses flexible polices that you tailor for different situations. So you might have a more permissive policy on a general-purpose workstation, and a stricter policy on a laptop. An Internet-facing server could be locked down very strictly. Don't forget your internal services, as the majority of compromises are inside jobs. Yes, Hollywood amuses us with colorful, unrealistic portrayals of stylish über-crackers who can break into any system anywhere with a few dramatic keyboard sound effects, and triumphant cries of "I'm in!" An outside attacker is more likely to bribe some starving, resentful perma-temp to get what he wants, or to thieve un-encrypted backup tapes from the beater car of the starving, resentful perma-temp who has to take them home every night. (Which demonstrate that physical security, and giving too much access to the wrong people, and stringing your temps along for years without hiring them, are also important problems in your security architecture.)

Fedora Linux has been shipping with SELinux since Fedora Core 2, way back in ancient times (2004). It didn't actually work then because it shipped with a strict policy of "deny all, allow as needed" policy. This turned out to be an uncomfortable choice for a general-purpose operating system; it was too difficult to use, so most users turned it off.

FC3 delivered a working implementation that used a targeted policy. This is "allow all, deny as needed." The default policies confined a limited set of processes, mainly networking applications that accepted incoming connections. Successive Fedora releases included better userland tools for configuring SELinux and more refined default policies, which we're going to look at next week.

Until then, please visit the Resources links to get more good background on SELinux and what to do with it. The Red Hat and Fedora teams have done a huge amount of work with SELinux, including a lot of excellent documentation.

Resources

• Fedora's SELinux Wiki
• Confined Domains shows which network services are targeted
• Exploits of a Mom demonstrates the perils of sloppy, insecure database coding