SolutionBase: Securing RedHat Enterprise Linux

In this day and age, security is Job 1 for most network administrators. In this article, Brien Posey shows you how to configure Red Hat Enterprise Linux for maximum security.

When you install Red Hat Enterprise Linux, then you know that the Anaconda installer gives you the option to enable or disable SELinux. SELinux (Security Enhanced Linux) allows you to have more granular control over security than you would have in a more traditional Linux deployment.

In my article on installing Red Hat Enterprise Linux, I briefly mentioned that you should enable SELinux as a part of the installation process, but that you should initially configure it to use Warn mode rather than Active mode. That way SELinux won't actually deny access to anything that wouldn't already be blocked. Instead, it gives you a warning message as you attempt to access forbidden resources. The message simply informs you that if SELinux were actively enforcing the security policies, then this particular resource would be blocked. The reason why I recommend setting SELinux to Warn is because doing so allows you to get a feel for how to use SELinux before you actually lock anything down.

Now that you have got Enterprise Linux installed and running, I want to revisit the issue of security based on SELinux. In this article, I will explain what SELinux is, why it is important, and most importantly, how to implement it.

What is SELinux?

The easiest way for me to explain what SELinux is, is for me to start out by asking you a question. That question is, "What would happen if a hacker figured out your Linux server's root password?" In a normal Enterprise Linux deployment, if a hacker figures out your server's root password, then that hacker owns your server, period, game over.

If you really stop and think about it, there is only one password standing between a hacker and total domination of your entire server. What SELinux does is compartmentalizes your server. The idea is that if a hacker were to gain control over a portion of your server, that one area would be the only thing under the hacker's control. I know that the idea of a hacker controlling even a portion of your server is unsettling, but by compartmentalizing the server, you can make sure that the hacker can not use the portion of the server that is under their control to gain access to other portions of the server. To put it simply, SELinux is designed so that it is impossible for a hacker to use a single exploit to gain control over an entire server.

The normal Linux security model is known as Discretionary Access Control (DAC). DAC is based on assigning permissions to users and groups. The problem with DAC is that if a user runs a process, the process has access to anything that the user has access to. The implications of this security model are compounded when you consider that many processes run as Root. SELinux on the other hand, uses a security model called Mandatory Access Control (MAC) the whole idea behind MAC is that you can grant a process the minimum amount of access that it needs to run, and nothing else.

SELinux security models

In SELinux, policies are used as a way of implementing one or more security rules. Policies are based on policy configuration files. These policy configuration files can be used to implement one of two possible security models: Type Enforcement and Role Based Access Control.

The Type Enforcement security model is based on the idea that every object contains a security attribute called a type. Likewise, each of the system's processes is linked to a security attribute called a domain. The Type Enforcement security model allows you to lock down the operating system in a way that ensures that the operating system objects that the user is allowed to access is are based on the domains within which the user is allowed to operate.

Role Based Access Control gets its name because it is based on the idea that each user account can be assigned a specific role. The various roles that are available are arranged in a hierarchical manner. The actual permissions are assigned to the role rather than directly to the user. The user inherits the permissions of the role that is assigned to them. Permissions are assigned to a role using the Type Enforcement Security model.

Earlier in this article, I mentioned that if you have not previously worked with SELinux security, then you should set SELinux to Warn mode rather than Active mode. The reason being that Warn mode causes you to see a warning message when you violate a security policy rather than actually being blocked from what ever resource you were trying to access. If you installed Red Hat Enterprise Linux according to my Linux installation article, and you have taken some time to play around with the operating system, you might have noticed that you do not receive a single warning message from SELinux.

The reason why you have not seen any warning messages yet is because SELinux runs parallel to your existing Linux security. SELinux does not replace or augment your existing security (except in strict mode, but I will talk about that later on). Even after SELinux is enabled, users still keep their existing accounts (the ones defined in the /etc/passwd file), and you can still manage security in the usual way. It is not until you actually begin to apply SELinux specific security that these various warnings become active.

Implementing SELinux

Now that I have talked a little bit about what SELinux is and why it is so important, let's talk about how you would work with it. Hopefully, you enabled SELinux in the initial operating system setup, but you should do a quick check just to make sure before moving on.

To determine if SELinux is installed and to see the current settings, open a Terminal window and enter the following command

sestatus -v | less

When you do, the Terminal screen will fill with SELinux related settings. For right now though, it's the first line that is important. It will tell you whether or not SELinux is enabled. As you look at this terminal screen, you will notice that it is split into two sections. The lower section is labeled Policy Booleans. It simply reflects whether the individual policies are active or inactive. Remember that a policy is just a collection of rules.

I will come back to the policy Booleans later. For now, I want to focus on the upper section of the Terminal window, because it contains some information that I have not discussed yet. Specifically, you should pay attention to the listing for the Current Mode and to the Policy From Config File.

The Current Mode will be set to Enforcing, Permissive, or Disabled. This goes back to what I talked about earlier with Warning Mode. A current mode of Permissive indicates that SELinux is set to Warning Mode. On the other hand, a current mode that's set to Enforcing means that SELinux is in full force. Of course if the current mode is set to disabled, then it means that all you have protecting your server is the standard Linux permissions.

The Policy From Config File will be set to either Targeted or Strict (the default value is Targeted). The idea behind targeted policies is that they target areas of your server that could be potentially vulnerable to attack, as well as the resources that those vulnerable services have access to. Specifically, targeted policies focus on Samba, FTP, Apache, FTP, and NFS to name a few. The targeted policies place boundaries around these services so that an attack against these services can not compromise the server as a whole (that's the theory any way).

Strict policies are a lot more complicated, but are also a lot more comprehensive than targeted policies. Strict policies allow you to apply security to virtually every level of your server. If you want to use strict policies, then you will have to install the selinux-policy-strict package.

There is one other thing that is worth pointing out in the Terminal window after the sestatus -v | less command has run. You will notice that the upper portion of the results listing contains a line that reports the policy version. This policy version is a little bit more significant than you might think. Remember that Linux is an open source operating system. The policy version points you to the policy file.

For example, on my test server, the policy version is 18. What this means is that if you were to go to /etc/selinux/targeted/policy, there would be a file named policy.18. This is the compiled policy set that is being used. If you want to modify the policy set, you can access the source files in the /etc/selinux/targeted/src/policy folder. If you make changes to the policy source, you can then compile it into the next policy version. The same concept applies to strict policies, you would just change the path to use the word strict rather than targeted.

Configuring a targeted policy

Now that I have discussed the basics of how SELinux policies work, let's take a look at how you would actually configure a targeted policy. In most cases, you won't even have to worry about doing this, because the out of the box targeted policy usually works fine. Even so, it is good to have an understanding of how security is being applied to your server so that you can make changes if necessary.

The Terminal screen that we have been looking at thus far is great for getting information regarding how policies are configured, but the screen is informational only. It doesn't allow you to change anything. The primary interface for interacting with SELinux is the Security Level Configuration properties sheet. You can access this properties sheet by selecting the System Settings | Security Level commands from Linux's Applications menu. When the Security Level Configuration properties sheet is displayed, the Firewall Options tab will be selected by default. To access the SELinux options though, just select the SELinux tab.

The upper portion of this tab contains three checkboxes. The first check box is labeled Enabled. This is the box that you would use to enable or to disable SELinux. Changing SELinux's enabled / disabled status requires a reboot.

The way that the second check box is labeled is a little confusing at first. On my test system, this check box is labeled Enforcing Current Permissive. What this check box is telling you is that SELinux is currently set to a permissive state (Warning Mode). If you select the check box, then you are enabling Enforcing mode.

The third check box is named Relabel on Next Reboot. The idea behind this check box is that if you switch from targeted mode to strict mode, the entire file system will have to be relabeled (presumably to support extended security attributes). You can make the switch to strict mode by selecting the Strict option from the Policy Type drop down list found just below the Relabel check box. Keep in mind that strict policies are complex, and switching to a strict policy mode is not an action to be taken lightly.

Modify SELinux policies

The last thing that I want to talk about is enabling or disabling various policies. Earlier, when I was talking about the sestatus -v | less command, I briefly mentioned that the lower section of the results listing contained something called the Policy Booleans. When SELinux is running in targeted mode, the various policies operate in Boolean mode. This means that a policy is either enabled, or it is disabled. There is no other possible state for a policy.

The results screen lists a dozen or so policies and tells you whether each one is enabled or disabled. The policies themselves are enabled or disabled through the Modify SELinux Policy section of the Security Level Configuration properties sheet's SELinux tab.

Earlier, I explained that targeted policies are designed to target specific areas of the server that tend to be particularly prone to attacks. If you look at the Modify SELinux Policy section of the Linux tab, you will see that each of these areas is listed. Now, suppose that you were concerned about attacks against the server's Name Service. If that were the case, you could just scroll through the list of services until you found the listing for the Name Service.

You will notice that there is a triangle icon next to each service. If you click the triangle icon next to the Name Service, it will expand the service's listing to display the policies related to this service. You can enable or disable each individual policy simply by selecting or deselecting the policy's check box. In this particular case, there are three different policies related to the Name Service, and none of those policies are enabled by default. You could therefore make the name service more secure by enabling the various policies. Keep in mind though that the actual services that will be displayed in the Modify SELinux Policy section vary depending on which services are running on your server.

Safe and sound

As you can see, SELinux can be used to greatly enhance a Linux server's security. Linux novices can implement targeted policies and gain a significant level of increased protection without having to go through a lot of work or complex configuration tasks. Those who require a higher level of security have the option of implementing strict policies, which provides total control over the entire server's security.