25 Coping with the SELinux Security

Technique System

Save Time By

Exploring the principles of SELinux

Understanding SELinux terminology

Disabling or disarming SELinux

Finding out about your security policy

Fedora Core 2 includes a new enhancement to the Linux kernel: SELinux. Other distributions will incorporate SELinux in later releases. You may not have to worry about it now, but this technique

will come in handy later. The SE in SELinux stands for Security Enhanced. The driving force behind SELinux has been the National Security Agency (NSA), which developed SELinux and donated the code to the open-source community.

The SELinux package is a collection of kernel modifications, program modifications, and configuration files that all work together to harden your computer against abuse. Old Linux kernels (pre-SELinux) grant all privileges to a special user named root (actually, privileges are granted to the user whose numeric user ID is zero, and by convention that user is named root). Any process whose user ID is zero is granted all privileges. A process running as user ID zero is called a superuser. If you log in to Linux as user root, you can do anything you want. If you log in as a nonprivileged user and then use the su command to become a superuser, you can do anything you want. If you break into a Linux computer and somehow manage to change your user ID to zero, you can do anything you want. SELinux changes that.

Under Linux, access rules are based on the user ID, group ID, and file permissions. With SELinux, access rules are determined by the policy file, and the rules are subject to change.

In this technique, we introduce you to SELinux. It’s a relatively new addition to the security force patrolling Fedora. It’s got some room to grow, but it shows a lot of promise as a timesaving way to super-harden your system.

Understanding the Principles of SELinux

When you enable SELinux, the kernel grants privileges based on three factors: the security context of your process, the security context of the object that you’re trying to access, and a database of access rules called

Understanding the Principles of SELinux

165

a policy. The important feature that SELinux brings to Linux is mandatory access control (MAC). A standard Linux kernel exercises discretionary access control (DAC). In a DAC system, a user can grant to any other user access to things that he owns, at his own discretion. DAC sounds friendly, but if you’re trying to run a secure organization, you don’t want us mere users granting extra privileges to our friends. In a MAC system, ownership and access are governed by a complex and customizable set of rules controlled by the organization.

The normal Linux security mechanism (access modes and user/group IDs) and the SELinux mechanism work together. Before a process can access an object, the process must satisfy both mechanisms. If your user ID has write permissions to a given file, it doesn’t necessarily mean that SELinux will give its blessing, too — it all depends on the policy.

SELinux introduces a few new terms to the Linux lexicon, and it helps to have a good understanding of those terms before going much further.

Everything is an object

An object is something that you can protect and something that you can access. The Fedora Core 2 security policy defines a number of objects: A file is an object, a file system is an object, a network socket is an object, and a device is an object. In all, the FC2 policy defines 12 top-level objects:

Files (and directories)

File systems

File descriptors (a handle to an open file)

Sockets

Network nodes

Network interfaces (eth0, ppp0, and so on)

Processes

IPC mechanisms (shared memory, semaphores, and message queues)

The SELinux security server

The system log (syslog)

Kernel capabilities (kill, reboot, set time, and so on)

Passwords

The policy also defines a number of fine-grained specializations, such as a program file versus a configuration file versus a data file.

Identifying subjects in SELinux

A subject is something that can act on an object (think back to your elementary school grammar classes, ugh). A process is a subject. Indirectly, a user is considered a subject, too, because a new process inherits its security context from the user. A program can also play a part in determining the security context of a process, so a program is often considered a subject as well.

Every subject and every object have an associated security context (or context for short). When a subject wants to access an object, the kernel compares the subject context, the object context, and the type of access requested against a set of rules called the policy to decide whether to grant or deny the requested access.

Understanding the security context

A security context is made up of three components: an identity, a role, and a type. You can see the context assigned to your login session with the command id -Z:

$ id -Z user_u:user_r:user_t

In this example, the identity is user_u, the role is user_r, and the type is user_t. If you’re logged in as user root, you see a different context:

# id -Z root:staff_r:staff_t