Selinux on FC5

Selinux can be confusing, but it's ordinary and default configuration is actually pretty simple. We'll examine it on Fedora Core 5.

By default, FC5 installs Selinux in "targeted" mode. You can see this in /etc/selinux/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.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0 
 

As the comments imply, only certain network daemons are affected by Selinux in this configuration. You can see which daemons are included and modify the security policies for them in a graphical tool ( System->Administration->Security Level and Firewall).

The idea here is that Selinux can prevent these daemons from misbehaving even if they escape from the ordinary permissions and controls that surround them. We'll use the httpd daemon to demonstrate this.

First, we need to turn httpd on if it isn't already:

# chkconfig httpd on
# /etc/init.d/httpd start

Next, I want to create a data directory:

# cd /var/www
# mkdir data
# chmod o+w data

Then we'll create a silly little cgi script to write something in that directory:

#!/usr/bin/perl
# this is /var/www/cgi-bin/se.pl
use CGI qw(:standard);
print header;

print "hello";
open(O, ">/var/www/data/foo");
print O "foo" or print "<br />Cannot $!";
print end_html;

Be sure to "chmod 755" that script. If you then visit "http://localhost/cgi-bin/se.pl", "hello" will apear on the browser screen and the file "foo" will be created in the data directory. You'd expect that, of course. But there's more going on underneath.

To see what that is, use the new "-Z" flag with "ls":

[root@localhost www]# ls -Z
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xrwx root root user_u:object_r:httpd_sys_content_t data
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual
drwxr-xr-x webalize root system_u:object_r:httpd_sys_content_t usage

"-Z" shows Selinux context for files. We don't need to entirely understand what this all means yet; just accept that -Z shows the details. You can also use -Z with ps:

[root@localhost www]# ps auxwZ | grep httpd
user_u:system_r:httpd_t root 27529 0.0 3.7 22616 9732 ? Ss 19:59 0:00 /usr/sbin/httpd

This shows that httpd is running in a specific selinux context (user_u:system_r:httpd_t). Again, we don't need to understand the specifics of what that means at this point.

If we look at the file "foo" that our script created, we see that it also has a context:

-rw-r--r-- apache apache user_u:object_r:httpd_sys_content_t foo

By default, files inherit selinux context from their parent directories. That's why "foo" has "user_u:object_r:httpd_sys_content_t". However, we can change it:

# cd /var/www
# chcon system_u:object_r:httpd_sys_script_exec_t data

All I'm doing there is making "data" match the "cgi-bin" directory's context.Selinux wouldn't allow httpd to write into its cgi-bin directory, so I just used that as a pattern.

If we reload the "http://localhost/cgi-bin/se.pl", it still works. The file "foo" already exists, and still has "user_u:object_r:httpd_sys_content_t". However, if we remove foo, the se.pl will now fail and complain "Cannot Bad file descriptor". Nothing else has changed: the directory permissions still allow Apache to create the file, but Selinux does not because we gave the directory a security context that httpd is not allowed to write to.

Remember, these contexts only affect daemons targetted by Selinux. Nothing else is constrained: root can still do anything it likes. However, if Selinux were NOT running just targeted daemons, even root could not bypass its security. Setting up system like that can be a little tricky (Selinux has a well deserved reputation for complexity), but if you'd like to read more about it, see these on-line books:

http://www.linuxtopia.org/online_books/getting_started_with_SELinux/index.html
http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.