What’s new in SELinux for Red Hat Enterprise Linux 5?

Dan Walsh will be presenting an overview of “What’s new with SELinux in Red Hat Enterprise Linux 5″ at the Red Hat Summit on Wednesday May 9th at 3:00 PM in the “What’s New” Track. This article presents some of the material from that talk, and was written with frequent magazine contributor Len DiMaggio.

This article has been corrected since its original publication.

Software security? Do I have to?

For many people, security is a subject that they only think about after something bad happens. Like buying a home alarm system after your home has been burgled. Why? One reason is denial–after all, bad things always happen to someone else. Additional reasons may be the perception that security, especially in software, is too hard. People either don’t use it, or use it incorrectly¹. Computer security may prevent you from performing tasks that you want to accomplish. Or the security is not all that effective.

In Red Hat Enterprise Linux 5, enhancements to SELinux address these problems by making the coverage more comprehensive, the tools easier to use and manage, and–at the same time–continuing to not require changes to application software.

This article examines these enhancements in greater detail. We will discuss other SELinux-related subjects in subsequent articles.

Lets take a look at SELinux, how it works, and what makes it effective. And why it should matter to you.

SELinux background

I like to begin technology discussions with a version of the question that Al Franken used to ask on Saturday Night Live. “What does this mean for Al Franken?”

So, here’s our question: What does SELinux mean for you?

The answer is that you, your personal information,, business information–including financial information–and intellectual property are at risk. If you think that you’re immune to this risk, you’re in denial. All you have to do to see examples of this risk is watch or read the news. In the past few months, literally hundreds of thousands of people world-wide have been directly affected by identity theft.

How does SELinux protect against these threats? How is SELinux different from firewalls, passwords, and other security software?

Security like file permissions or user account passwords are Discretionary Access Control (DAC) systems. They are referred to as “discretionary” because every object (files and directories) has an owner, access to objects is based on user identify, and users (the object owner or root) are able to–at their discretion–grant access to other users. In contrast, SELinux is a Mandatory Access Control (MAC) system. Access to objects is controlled by a system-wide policy, regardless of the ownership of any object, enforced by the kernel. Users, including the root user, cannot grant other users access to their objects in violation of the policy. Using a MAC security system requires a different mindset. When people first encounter a permission violation enforced by SELinux, they often try to diagnose the problem by checking the ownership of the file and the read/write/execute permissions on the object. But even if the ownership and permissions are correct, the access is still blocked. The user and file/dir ownership is not the deciding factor with SELinux, the policy is.

Why is this distinction important? Here’s an example. Let’s say that you’re running an http server for a retail web site paired with a mysql database containing customer data (including credit card information). The software that runs the web site has a security vulnerability. If someone breaks into the server, what’s the risk to your system? it’s just the web sever, right? Wrong! Suppose the attacker is able to obtain a root shell. With root on a non-SELinux system, he can access your credit card database. Once the attacker gains access through the web server, the whole system is at risk. If this same system was protected by SELinux, the user might be able to use the vulnerability to break into the web server, but he would be prevented from touching the database or any other parts of the system, even if he got a root shell. SELinux would only allow the http process to communicate with the database through the named pipe. In other words, with SELinux, you don’t trust the application²–which may be buggy, insecure, or compromised–to secure itself. You rely on the SELinux policy.

This diagram illustrates the httpd web server example:

SELinux provides security to a system in a way similar to a ship or submarine’s design. They are divided into multiple water-tight compartments. If the ship springs a leak in any one compartment, only that compartment will fill up with water.³

The following diagrams illustrate this difference:

A vibrant community

Before we discuss enhancements made to SELinux in Red Hat Enterprise Linux 5, I want to make one very important point about what sets SELinux apart from other security software. SELinux could not have been developed and would not be as reliable, comprehensive, and effective if it was not supported by a vibrant open source community.

SELinux, as implemented in Red Hat Enterprise Linux 5, is a direct result of the work on earlier versions in Fedora(TM) Core (FC) 2, 3, 4, 5, and 6, as well as Red Hat Enterprise Linux 4. It’s unlikely that a system as comprehensive, integrated, and robust as SELinux could have been created without the work of the community. The scale and complexity of the task is too large for any closed organization or corporation. The community gives SELinux access to millions of potential users, testers, and contributors. The testing/QE effort alone is huge⁴.

But wait–couldn’t a large, well-financed corporation achieve the same results through a public beta test? Not likely. Think of your own experiences with beta software. You download it, then simply stop using it when something goes wrong. Within the Fedora Core community, however, SELinux users are more actively involved, often personally invested in the software⁵. The community doesn’t only report bugs, but also contributes patches (for example, SELinux policy changes). When I refer to the SELinux community as being “vibrant,” I chose my words carefully. In this regard, it is a classic example of an open source project that has migrated in stages from the community tthrough Fedora Core and into Red Hat Enterprise Linux. This diagram illustrates these stages.

SELinux = Red Hat Enterprise Linux

SELinux is not a set of packages, add-ons, or optional extensions layered onto an older version of an OS. When you use SELInux on Red Hat Enterprise Linux 5, you’re running Red Hat Enterprise Linux 5. All of it. In comparison, versions of Trusted Solaris trail the mainstream version of Solaris by months–if not years⁶. With SELinux, you don’t give up any of the current features or enhancements in Red Hat Enterprise Linux 5. And your applications don’t have to change, either.

We started this article by asking what SELinux means to you. Now, let’s talk about what the most recent enhancements to SELinux mean to you. What’s new in SELinux in Red Hat Enterprise Linux 5? Let’s take a look.

Doing more with comprehensive system space coverage

In the context of describing the how SELinux protects a system, there are two categories of system usage: system space and user space. System space refers to all programs started during the bootup process. Some examples are crond, named, and services such as httpd and mysqld. User space refers to programs started by a logged-in user.

In Red Hat Enterprise Linux 4, 15 services ⁷ in system space had confined SELinux domains defined. In Red Hat Enterprise Linux 5, over 200 processes are confined by SELinux. The improved SELinux policy is much more precise in how it governs the operation of these services. It’s far less likely that a Red Hat Enterprise Linux 5 system space process will be compromised or encounter an error caused by an SELinux policy not handling the specific requirements (e.g., file or directory access) of a service.

User space applications will be locked down in future Red Hat Enterprise Linux releases. In Red Hat Enterprise Linux 5, logged-in users still run mostly unconfined by the SELinux policy, although the building blocks are in place for confining certain users. There are a couple of things to remember about user space in Red Hat Enterprise Linux 5. First, in the context of SELinux, a “logged-in user” refers to those that have accessed the system via the login, sshd, or xdm programs. This is different from an exploit (such as a break-in via httpd) where a user shell is opened. This type of attack would be confined by SELinux’s handling of the httpd process. Second, even in the unconfined user space, SELinux protects against buffer overflow attacks by performing executable memory checks. Buffer overflow attacks are a classic system exploit technique. An overflow writes more memory than a buffer is configured to hold, and includes executable code in the data being written. In Red Hat Enterprise Linux 5, SELinux checks memory to ensure that what should bewritable is not changed to be executable.

Easier management

One of the problems with any Mandatory Access System like SELinux is that confined applications get permission denied, and administrators have no idea why. Over the years, UNIX/Linux administrators have learned that permission denied means that an application either does not have ownership of a file/dir, or it does not have the correct read/write/execute privilege. With SELinux, they look in /var/log/messages (or if auditing is turned on the messages end up in /var/log/audit/audit.log) and see this:

logtype=AVC msg=audit(1176392795.244:2036): avc:  denied  { getattr } for  pid=6705 comm="httpd" name="index.html" dev=dm-0 ino=3180003 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file

The universal first reaction of most admins is to say: “What the h**l is that?” What makes log messages like this so difficult to read is that they are not intended to be human readable. (Pardon the pun.) The format of these log messages is a set of name=value pairs that can be parsed programmatically.

In Red Hat Enterprise Linux 5, we have added a new program called setroubleshoot. This daemon watches the audit logs for SELinux-generated errors and translates them into human readable form.

SELinux access denial error messages like the example above are no longer written to /var/log/messages, they will show up in /var/log/audit/audit.log and setroubleshoot will translate these messages and write them to /var/log/messages. For example, in Red Hat Enterprise Linux 4, a message like this would have been written to /var/log/messages or /var/log/audit/audit.log:

time->Thu Aug 24 15:50:58 2006
type=AVC_PATH msg=audit(1156449058.917:552):
path="/var/www/html/index.html"
type=SYSCALL msg=audit(1156449058.917:552): arch=40000003 syscall=196
success=no exi
t=-13 a0=8d4d4d0 a1=bfb5e97c a2=434ff4 a3=2008171 items=0 ppid=23799
pid=23805 auid=3267 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=user_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1156449058.917:552): avc: denied { getattr } for pid=23805 com
m="httpd" name="index.html" dev=dm-0 ino=6260297
scontext=user_u:system_r:httpd_t:s0
 tcontext=system_u:object_r:user_home_t:s0 tclass=file

In Red Hat Enterprise Linux 5, this message is written to /var/log/messages:

Aug 24 15:53:10 localhost /usr/sbin/setroubleshootd:      SELinux is
preventing /usr/sbin/httpd "getattr" access to /var/www/html/index.html.
See audit.log for complete SELinux messages.

At the same time, the following screen icon is displayed for the user.

When the user clicks on that icon, the setroubleshoot (“SELinux Troubleshooter) utility is opened. Setroubleshoot analyzes the error messages, provides a detailed description, and offers a remedy. Here’s an example of what setroubleshoot displays for users:

Easy configuration and customization

In order to modify the current SELinux policy on a system running Red Hat Enterprise Linux 4, a system administrator would have to download the policy source, edit the policy source code, and rebuild and install the policy using tools like “make install.” The introduction of policy modules made this process easier and less error-prone. A system administrator could use the audit2allow utility to generate policy module updates directly from audit.log error messages. These modules function in a way similar to kernel modules in that they enable system administrators to modify part of the policy (a specific module) without having to rebuild the entire thing. So if you had an AVC message that was preventing an application from running httpd, you could simply execute the following to update the policy.

grep httpd_t /var/log/audit/audit.log | audit2allow -m myhttpd; semodule -i myhttpd.pp

Certain confined domains can be run in multiple different ways. Policy writers have the ability to write if/then/else code in policy, and let the administrator set up the policy they prefer. These if/then/else switches are called booleans. Configuring and customizing a policy is made easier by the system-config-selinux utility. This GUI utility lets system administrators modify the policy by selecting changes from a set of pre-defined booleans. With the system-config-selinux utility, the administrator can concentrate on understanding the specific security needs of his/her system. Changing the policy is as simple as selecting check boxes. Also, if the system is set up to run an application one way and the policy is set up differently, setroubleshoot will suggest the boolean needed for the code to work properly.

System administrators sometimes need to change the layout of their systems. For example, they may want to put the http pages in /opt/www rather than /var/www/html. In Red Hat Enterprise Linux 4 they could do this by editing the configuration file /etc/selinux/targeted/contexts/files/file_context.local. In Red Hat Enterprise Linux 5, there is a new command semanage fcontext -a which allows you to make these changes permanently. system-config-selinux also has a screen for this. And sometimes administrators want to change the ports that a confined domain listens on. In Red Hat Enterprise Linux 4 they would have had to modify policy. In Red Hat Enterprise Linux 5, semanage and system-config-selinux have the ability to change the ports.

Conclusion

Threats to your computer system and your data are real. And they are not static. They are always evolving to be more effective and dangerous. In order to keep your data, your system, and your home directory safe, SELinux is not static either. It is constantly evolving to be more effective and easy-to-use, from the introduction of GUI-based utilities to improved error reporting. The implementation of SELinux in Red Hat Enterprise Linux 5 is the result of experience gained over several Fedora Core releases and the hard work of contributors from a vibrant open source community. And it’s certainly not the end of the evolution of SELinux. It’s just a step along the way.

So turn SELinux on and keep it running. Don’t end up like Sidney in this–mostly based on fact–conversation (names have been changed to protect the, uh, innocent⁸):

Sidney:  This application stinks. It keeps crashing.
Walter:   Did you look /var/log/messages?
Signey:  (Embarrassed) No – OK I will
Walter:   (Smiles knowingly)
Sidney:  What's with all these SELinux log messages?
Walter:	  Oh, the application is attempting an action prevented by the policy.
Sidney:	 SELinux? OK, I'll just turn it off.
Walter:	  While you're at it, why not stuff $100 bills in all your pockets and go for a walk in the park at midnight?
Sidney:	 I would never do that – it wouldn't be safe!
Walter:		(Smiles knowingly)

References

• http://fedoraproject.org/wiki/SELinux/Understanding
• http://danwalsh.livejournal.com/
• https://hosted.fedoraproject.org/projects/setroubleshoot