March 21st, 2006

Key components of SELinux: Applications

Back to SELinux for Dummies...


When I usually give my SELinux talk, I have a section on Key components of SELinux and I usually start out talking about the kernel. But I find that most people understand that SELinux is integrated in the upstream kernel. The kernel has many access checks built into it, and the access checks call into the Linux Security Module (LSM). But I am not a SELinux Kernel Engineer, nor do I play one on TV. So I will leave it to the Stephen Smalley's and James Morris's of the world to explain the SELinux Kernel. Besides this is SELinux for dummies, and we know that no dummies work on the kernel. :^).

Most of the papers on SELinux talk about the Kernel, and how this integration happens.


The more interesting part in my opinion is how the rest of the Base Operating System uses SELinux. Of course that is what I work on ...

Most user applications and server applications unchanged SELinux aware applications. Of the hundreds/thousands of rpm packages in a Fedora only about 50 are compiled with SELinux awareness in them. This is one of the powerful features of SELinux in that applications do not need to be aware of SELinux.

The power of this is that it is fairly easy to write policy for a new daemon. You do not need to be a "C" programmer or fully understand the way the application works, but you can confine it with policy.

One problem with this, that you may have seen is that since an application is not aware if it is being blocked by Discretionary Access Control, or Mandatory Access Control. It just gets EPERM, Permission Denied. Administrators can become confused by this.
For example an administrator sets up a web page, the permissions on the files and ownership of the file are set correctly, yet apache reports permission denied. The file context on the files are set incorrectly, but apache has no awareness of this. We are working on tools to make this more obvious to the Administrator, but for now they need to know to look in the
/var/log/messages file or /var/log/audit/audit.log for AVC messages.

So which applications need to be SELinux aware?

  • Applications used to view or manipulate security contexts (Core Utilities)
Examples of this are the ls for viewing file context, ps for viewing process context.

  •   Programs required to set user session security context
The login programs are the most obvious programs for this login, sshd, gdm ... Also cron

  •   The SELinux core programs.
These are used to control/manipulate security context. chcon, setfiles, restorecon
Used to manipulate policy: load_policy, check_policy, check_module, semodule, semanage, setenforce, getenforce, setsebool, getsebool ...

Core Utilities

"Z" is your friend...

When I took over maintenance of the SELinux userspace I settled on to using "Z" as the universal option to show security context.

So "ps auxZ" will show you the security context of all processes. "ls -Z" will show you the security context of files. "id -Z" will show you the security context of your login shell.

So if you think an application might be SELinux aware try the -Z option...

Find command:

The find command has a powerful SELinux option "-context". This allows you to search for files matching a certain context. It uses a "glob" syntax to you can execute a command like

find /etc -context '*net_conf_t'

To find all the files labeled with type net_conf_t.

Another handy find option is:

find /etc -context "*net_conf_t" -printf "%p %Z\n"
/etc/sysconfig/networking/profiles/default/resolv.conf system_u:object_r:net_conf_t
/etc/resolv.conf.windham system_u:object_r:net_conf_t
/etc/ system_u:object_r:net_conf_t
/etc/ntp.conf system_u:object_r:net_conf_t
/etc/ntp/step-tickers system_u:object_r:net_conf_t
/etc/resolv.conf.old system_u:object_r:net_conf_t
/etc/yp.conf root:object_r:net_conf_t
/etc/resolv.conf.redhat system_u:object_r:net_conf_t
/etc/resolv.conf system_u:object_r:net_conf_t

Continued tomorrow:  mv/cp/install