• Login
• Become a member
• RSS
• Part of the TechTarget network

Security Enhanced Linux (SELinux), an open source project sponsored by the National Security Agency to help implement mandatory access controls (MAC), was first introduced in Red Hat's distribution with Red Hat Enterprise Linux 4 (RHEL4). In our review of RHEL4 and SELinux in 2005, we were excited about the possibilities and the GUI interface that came with it, but we were cautious about the software package's ability to capture the market. Despite the user-friendly GUI, SELinux was difficult to configure and hard to understand. The documentation wasn't much help either. Most administrators were just turning off SELinux.

Red Hat clearly understood that some changes were necessary. They were either intimidated by its complexity or feared the possible damage that a poorly configured system could do to their applications. On RHEL 4, there was no easy way to determine why, if an application stopped working, whether or not the problem was due to SELinux.

Red Hat hopes to change this with several new features and enhancements in RHEL 5. New monitoring tools, multi-level security integration, policy modules and utilities will provide RHEL5 users the added security of SELinux with less difficulty.

SELinux Troubleshooter
One of these enhancements is the new SELinux Troubleshooter. Written in Python, setroubleshoot is a tool that watches the audit log files for access vector cache (AVC) messages and sends reports when things

go bump in the night. The daemon continuously watches audit logs for errors and then translates them into laymen's terms for you. SELinux denials were one of the most common problems that administrators reported, which is why most decided to deactivate SELinux. Another daemon, setroubleshootd, receives connections which examine the data and alerts listeners. This tool maintains its own log file, under /var/log/setroubleshoot, and includes the use of the sealert command. This is a GUI desktop notification function, which contacts setroubleshootd, the local server daemon, and essentially registers itself as an alert listener.

To begin, start the browser:
# sealtert –b

This system is made up of three components, including the alert feature, setroublesoot and the audit subsystem. The audit subsystem reports the actual AVC messages. When the kernel sends a message that SELinux denies authorization for something, it creates this AVC message. Each message is tagged into a denial event, which setroubleshoot can assemble into complete events. The tool merges all these independent messages into single denial events.

New domains, policy modules
The extent that SELinux monitors the operations of services in RHEL5 has significantly increased since the last version. In RHEL4, only fifteen services had domains defined, while in RHEL5 over 200 target services are governed by the SELinux system. It is recommended that every program shipped by Red Hat and started on boot should have a domain defined. The benefit here is that it is much less likely for processes governed under SELinux running on RHEL5 to be compromised, increasing the comfort of security administrators. Another benefit is the introduction of policy modules, which make the process of modifying SELinux policies much easier. In RHEL4, one had to go through many steps (downloading source, editing code, using make) to rebuild the policy tools. With policy modules, these setups are not necessary. The audit2allow utility gives you the ability now to generate policy modules (allow rules) directly from audit.log messages. One can also configure these polices using the system-config-selinux utility. This much improved GUI lets you modify the policy you need changed from a set of pre-defined parameters. Also, it is very easy to change system policies. You no longer need to edit configuration files, you only need to check or uncheck boxes. This is available out of the box and is fully integrated with RHEL5.

You can also use the semanage utility to configure elements of these polices without any recompilation of policy sources. The semodule command is another useful one. For example, this command lists out the policies:

[root@172_29_137_21 selinux]# semodule -l amavis 1.1.0 ccs 1.0.0 clamav 1.1.0 dcc 1.1.0 evolution 1.1.0 iscsid 1.0.0 mozilla 1.1.0 mplayer 1.1.0 nagios 1.1.0 oddjob 1.0.1 pcscd 1.0.0 pyzor 1.1.0 razor 1.1.0 ricci 1.0.0 smartmon 1.1.0

Multi-level security integration
Another important enhancement is the multi-level security (MLS) integration into RHEL5. This model allows RHEL5 to get EAL4+ LSLPP certifications, which means that RHEL5 is now considered a trusted OS and can be sold to Government agencies which require the tightest security polices. MLS allows users to label files with categories. To turn the system into a trusted system in RHEL 5, install the policy (using the selinux-policy-mls utility) and make changes to the selinux config files to reference MLS. Prior to MLS, there was Type enforcement (TE), which is the primary mechanism and role based access control (RBAC). I'm still not thrilled about the fact that Red Hat still does not have a special SELinux guide for RHEL5. If Red Hat is really going to make SELinux an important part of its distribution, it needs to provide strong documentation so users do not have to fumble through the web looking for pieces of information. While there have been major improvements and tighter integration between RHEL5 and SELinux, Red Hat still has a way to go before it is user friendly enough for most IT departments. Better documentation will help in their efforts. The small chapter in the RHEL deployment guide (Chapter 43, Security and SELinux) isn't enough.

Deploying SELinux
Let's look at the Z parameter. Many utilities such as ps, lsof and netstat are optimized for SELinux, using the Z parameter.

[root@172_29_137_21 selinux]# ps -aeZ | more LABEL PID TTY TIME CMD system_u:system_r:init_t 1 ? 00:00:01 init system_u:system_r:kernel_t 2 ? 00:00:00 migration/0 system_u:system_r:kernel_t 3 ? 00:00:00 ksoftirqd/0 system_u:system_r:kernel_t 4 ? 00:00:00 watchdog/0 system_u:system_r:kernel_t 5 ? 00:00:00 migration/1 system_u:system_r:kernel_t 6 ? 00:00:00 ksoftirqd/1

Where SELinux is not installed, this is what you will see:

[root@172_29_137_21 selinux]# netstat -Z SELinux is not enabled on this machine.

We can also run the sestatus and genforce commands for further information on the status of SELinux on our system.

[root@1 [root@172_29_137_21 selinux]# sestatus SELinux status: disabled [root@172_29_137_21 selinux]#72_29_137_21 selinux]# [root@172_29_137_21 selinux]# getenforce Disabled [root@172_29_137_21 selinux]#

How can we turn on SELinux when it is disabled? The simplest way is to edit the selinux config file and change the SELINUX parameter, which can take three values: enforcing, permissive and disabled. In our case, we made it permissive. This is the option where alerts will be sent, though polices will not yet be strictly enforced. I recommend this as a good first step towards SELinux deployment.

# 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. SELINUX=permissive # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted

After editing this file you must reboot your system in order for the change to take effect. Let's look at the status now, after the reboot.

[root@172_29_137_21 ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted

Perhaps the best new utility available is the system-config-selinux utility. Almost everything can be displayed or configured from here. If you are using X, make sure that you turn on x11 forwarding on your ssh client.

************************************************************* [root@172_29_137_21 ~]# system-config-selinux /usr/share/system-config-selinux/system-config-selinux.py:68: Warning: IA__g_object_get_valist: object class `GnomeProgram' has no property named `default-icon' xml = gtk.glade.XML ("/usr/share/system-config-selinux/system-config-selinux.glade", domain=PROGNAME)

SELinux and RHEL5 are a better marriage than SELinux and RHEL4 ever were. The utilities are more focused, more user-friendly and more powerful. Setting up policies and administering the systems are easy and MLS, allowing this Linux distribution to be certified as a trusted system, is icing on the cake. Red Hat should publish more detailed documentation on SELinux and RHEL5: until that happens, I fear that administrators will continue to shun SELinux.

About the author: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist. .

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

All Rights Reserved,Copyright 2003 - 2013, TechTarget