Think before deploying Security-Enhanced Linux in RHEL 4

One of the most exciting new features in RHEL v.4 is the implementation of Security-Enhanced Linux. In this tip, Ken Milberg looks at how you can use it to beef up system security.

One of the most exciting new features in RHEL v.4 is the implementation of Security-Enhanced Linux (SELinux). In this tip, we'll look at how you can use it to beef up system security.

SELinux is an open source project sponsored by the National Security Agency, to help implement mandatory access control. It is a subsystem which provides a much more secure framework to Linux, then can be achieved from the operating systems level. It implements mandatory access controls that give you finer granularity in terms of security measures and is made up of both kernel and user-space components.

In SELinux, privileges are specified rather then relying on the typical Unix/Linux method of doing things, which is by user and group. This is done by using role based access controls. The two common roles are the user_r role and the system_r, for system administrators.

Be forewarned, if you are have servers (Web or DNS) that are exposed to the Internet, then one should look very strongly into how SELinux might help. If you are just running things like Oracle servers internally, with no external access, you may not want to go through the trouble, as there is a lot to learn and more to do. One might even need a special type security type administrator, as security will no longer just be the domain of the user that handles their files alone, it could be managed centrally by this administrator. If you use Linux as your firewall, think about putting it here as well. The key word here is think before you deploy.

A quick look at the /etc/selinux/config file tells you the information about your system values and the policies that are currently in use.

[root@redken selinux]# more config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
[root@redken selinux]#

One has three choices with respect to SELinux when installing the system. They are enforcing, permissive and disabled. I chose to install my system in permissive mode (one of the two modes available in SELinux), as I did not want it to interfere with my application while I was doing testing. To view violation type entries, one must look in /var/log/messages. After getting a feel for the types of violations that are entered here, at some point one might want to activate enforcement mode.

Though one can have multiple policies on an installed system, only one can be active at any time. The two types that exist are 'targeted' and 'strict'. A targeted policy generally runs without restrictions, where strict is a policy that partitions processes into security domains that are confined by policy.

Roles will determine ultimately, the commands that a user is allowed to run. If you log in as a normal use, you might see this:

[kem@redken ~]$ id –Z

This shows that you are a regular user, as opposed to root. When you log in as root, you will see this, after running the id command:


If you examine the htppd daemon, with an ls -Z, you will see this:

-rwxr-xr-x root   root   system_u:object_r:httpd_exec_t  /usr/sbin/httpd.

That shows that the file is owned by the httpd domain, and that user kem, is not in the domain. If you want to grant him access, you can then manually put him in the domain.

There is even a GUI tool for the policies that gives one the ability to perform configuration for each service and which also allows you to perform tasks such as changing settings and limiting file access. From the Linux command line, type in << system-config-securitylevel >> (or choose Security Level, off the System Settings button, from GNOME), which starts up the GUI. From here, I was able to disable SELinux protection for the httpd daemon, fairly easily.

The supported services for the GUI configuration include DNS, NIS, HTTP and DHCP, though I would stay away from clicking too much on this menu, until your really understand more about SELinux. Please note that if you choose to enable or disable SELinux, this requires a reboot for the change to take effect.

Try using << sestatus >>, a nice utility that gives more detailed information about the system. Here is some of the output I received from running the command.

[root@redken users]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 18

This shows that SELinux is running (and enabled), the mount point for this file system, the mode that I am running in (permissive mode) and the policy version , which shows the version that is supported by the kernel.

If you want to view the security context of processes, do a ps –Z (or a ps –efZ for the entire process table. Here's an example:

ps -Z

LABEL               PID TTY     TIME CMD

root:system_r:unconfined_t 3110 pts/2 00:00:00 bash
root:system_r:unconfined_t 24269 pts/2 00:00:00 ps

Setting policies and rules from the command line and editing SELinux text files are not for the faint of heart. There is a lot to learn if you are thinking about turning on SELinux, especially in a production environment. For some more information, go to the SELinux section of the National Security Agency's site.

Hopefully, Red Hat will come up with some good documentation to help end-users implement SELinux in a Red Hat environment; documentation that includes a best practices summary. They also need to document some of the Red Hat-specific configuration changes that are unique in this SELinux configuration, as the location of many files and directories are different in this implementation.

Here's a link to the RedHat SELinux guide. Thanks to Stefan Wiederoder for the link. - Editor

This was last published in April 2005

Dig Deeper on Linux system security best practices



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: