Last week Evelyn, Kevin, Scott and I were talking about SELinux. I forget who came up with the idea first, but it's useful to think of SELinux as the software equivalent of what the firewall is to the network. Read on for more about why this is a good thing.

SELinux has gotten a lot of attention recently. Some of it good, like being accepted into the mainline kernel and being on by default in Fedora Core 4. Some of it bad, like it going through many changes between FC-4 and FC-5, and not really getting more usable between the two releases. As with many things, many of these changes were to pave the way for future improvements, allowing packages to more easily customize the SELinux contexts as new software is added to the system.

Still, unless your needs are fairly modest, the stock setup for SELinux under Fedora Core 4 and 5 is unlikely to be usable for you. The "audit2allow" tool (as discussed in the related article, above), makes it fairly easy to patch up the SELinux contexts so that the appropriate things are allowed for applications you may be running. Of course, without careful use of these tools, you may end up allowing too much, at which point you might as well just have disabled SELinux.

However, when configured correctly, it can provide significant security enhancements. For example, Kevin has configured his firewall so that the "root" account has no special privileges, so even if someone were able to do a root exploit they wouldn't have any special privileges. Of course, this was a quite extensive amount of work.

Getting back to the firewall analogy... Many people wonder about the usefulness of a firewall on a properly patched system. If all of your software is patched to prevent exploits, why does firewalling off traffic make you any safer?

Of course, firewalling can block many Denial of Service attacks, but one of the significant benefits is that it is a confirmation of the software you expect to be running. Your system is running software from hundreds or thousands of packages, comprising hundreds of thousands of files. These collections of applications have been carefully selected by the distribution maker, and while the collection of packages installed should be reviewed by the system administrator, setting up a firewall confirms what your expectations are.

When you set up a firewall, it is a single location where the system administrator specifies exactly what applications they expect the server to be publishing on the network. Ideally, the firewall should be short. There are plenty of massive firewall scripts that have lots of tunable knobs, unless you have some really specific needs I recommend a firewall be as short as possible, so that it can be easily reviewed. For example, on a web server maybe something like:

iptables -P FORWARD DENY
iptables -P INPUT DENY
iptables -A INPUT -m tcp -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

In other words, set the default policy on both INPUT and FORWARDED packets to DENY, and then only allow port 80 (HTTP) and 443 (encrypted HTTP), and traffic related to these. Of course, you'd probably also want SSH in here, but you probably want to protect it in various ways.

This sort of firewall lets you look in one place and see that, even if you accidentally have another program running that you don't intend, that you are unlikely to be exploited by the network except for by the web server.

In other words, you are stating in another location what your expectations are about the network services available on your system.

SELinux provides another way of doing similar sorts of things, but at the system instead of network level. For example, the problem with the above firewall rule is that it doesn't further restrict what the web server can do. The above firewall rules could quite easily allow someone to inject (into a PHP or other script) shell commands which download and runs a program which connects to an IRC server and waits for further commands.

However, with SELinux you have full control of the application context. You could, for example, restrict the web server user from being able to write files anywhere but "/var/www/sessions", only allow executing programs in "/var/www/cgi-bin", and not even seeing files outside of "/var/www" at all.

This protects against a very prevalent attack these days: web application bugs. For example, some attackers search on google for unsecured access to particular versions of the AWStats program of a particular version or earlier. They then use that URL to inject commands into the system which download and run software allowing the attacker to get shell access to the system.

Tools such as SELinux can, by preventing this attack, significantly increase the security of your systems and prevent a large source of denial of service attacks from getting any traction. Remember, many compromised systems are used to attack and compromise other systems, and those attacks often can completely take your sites off the air until the problem is found and repaired.

Also like a firewall, SELinux can make your systems more forgiving of errors in software and administration. For example, if your staff is away or otherwise occupied when a security-critical update is announced, you may have more time to apply those updates without an attack being able to successfully exploit your systems.

While SELinux can require significant effort to setup and maintain, particularly if your system runs many third party or custom applications, in today's Internet tools like SELinux are practically a required part of a "best practices" system configuration.
(Post Reply)