
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.
More Linux Security
- Master iptables with GUI Firewall Builders
- SELinux: Spook Tested, Admin Approved
- Linux Security: Tips from the Experts
- Bastille: Classic Linux and Unix Security
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.
More on chroot
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