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:

Next, I want to create a data directory:

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

Be sure to "chmod 755" that script. If you then visit "https://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":

"-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:

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:

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:

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 "https://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:

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

Got something to add? Send me email.

1 comment

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us