SELinux Identities

In addition to the normal permissions structure you are used to in Linux, SE-Linux adds another layer called Mandatory Access Control. These permissions revolve around the issue of your system identity, which is tracked at a lower level than your actual login. For example, if you use the su command at a command prompt to temporarily log in as another user, your identity assignment doesn't change; it is tracked through the su session. The id -Z command that we used previously will show something like the following as the SELinux identity context, which is listed in the format of identity:role:type. Let's say we have
this example:

context=user_u:system_r:unconfined_t

The first entry in the context is your identity. When you see user_u, it means you're assigned to the group of valid, nonadministrative users. (Your user account is valid if it exists on the system.) If user_u hadn't been defined in your SELinux policies by your distro, then only users who had explicit SELinux identities would be able to log in. The account in this example has no explicit identity (because you don't see the login name in the identity location). The explicit identity doesn't have to be the same as the login name, but these two items usually are identical to help make keeping track of things easier.

Processes on your system also are given identities to help keep them confined to only what they're allowed to do. If you have SELinux, at a command prompt, type ps -axZ (as shown in Figure 1) to see the contexts assigned to the processes you have running. You'll also see the identities as-signed to the processes. For example:

LABEL PID TTY STAT TIME COMMAND

user_u:system_r:unconfined_t

1 ? S 0:01 init [5]
root:system_r:unconfined_t

413 pts/1 S 0:00 -bash

Note that the root identity now appears. This is the root account's identity. On some distros if you type su - at a command prompt to become root, your identity changes to match your initial login account. For example, if you logged in as bob and changed to root, typing id -Z would show something like bob:system_r:unconfined_t unless you ran the newrole command to change your identity from bob to root. In the other distro, the su command has been set up to include the newrole.

It's not just users and processes that have identities; files do, as well. At a command prompt, type ls -aZ (shown in Figure 2) to see for yourself. For example,

you might see something like:

-rw-r—r— root root user_u:object_
r:user_h ome_t anaconda-ks.cfg

-rw-r—r— root root user_u:object_
r:file_t install.log

Another generic identity you might run into is system_u, which is assigned to system processes and system resources (such as files and more).

SELinux Roles & Types

The second entry in a SELinux context is your role. In the previous examples, these roles were system_r and object_r. A system_r role is typically for system processes, while there is also a user_r for regular users and a sysadm_r role for administrators (plus other roles). Any account that a system administrator uses should have the sysadm_r role assigned or at least available. The object_r role is assigned to all files. Essentially, SELinux considers everything on a system that isn't a process or a user to be an object.

The third entry in a SELinux context is the type. This term actually is an umbrella that includes types and domains. A domain specifically refers to processes, and types refer to everything else (such as objects). In the case of our examples, the types shown are unconfined_t, user_home_t, and file_t. The unconfined_t entry is also used for a domain for the processes.

The unconfined type and domain are items that SELinux isn't worried about applying restrictions to. Each user's home directory is assigned the user_home_t type, while by default most files are assigned with file_t. Another common type is the sysadm_t, for various system administration-related processes and files. To learn more about the types and domains you'll run into, read the NSA's policy paper at www.nsa.gov/selinux/papers/policy/policy.html.

Pull It All Together

Knowing the components of a context listing, you now need to know how SELinux takes this data and uses it to determine who can do what. SELinux consists of a set of security policies (which the NSA policy paper explains). These policies map what identities within what roles can access particular files and run or interact with particular processes in terms of their types and domains. Where these policies are stored depends on your distribution, so see your distro's documentation for details.

Some current distros offer GUI tools to interact with your policies. Fedora Core 3, for example, offers this tool, which you can access by selecting Applications, System Settings, and then Security Level. Doing a Web search on "selinux gui tool" will offer up distribution-independent options that you can download and install.

A good source for tools and documentation is Tresys Technology (www.tresys.com/selinux). Before you start messing with policies, however, know that if you make mistakes, you can lock out others from being able to use the system, keep processes from functioning properly, and worse. We highly recommend that you bring up a system with a new set of policies in a mode that will not enforce the policies but will log what you would do if you were enforcing the policies. This may be called various things (such as Warn mode) de-pending on your distribution. The official name is Permissive mode.

When you're convinced the system works OK, you can change to Enforcement mode. Now test it again. Only when you have really tested and made sure that everything is working properly should you walk away and let SELinux control your production systems in Enforcement mode.

Not Simple Security

SELinux isn't a simple security implementation. Just researching the topic can make your eyes cross. Keep experimenting on a system you can afford to make errors on until you feel you have a grip on it. For the average user, SELinux might even be overkill. For server admins, however, it may eventually be a mandatory addition to the security-solutions tool belt.

by Dee-Ann Leblanc