166 Technique 25: Coping with the SELinux Security System

The FC2 policy doesn’t create an identity for every user: Nonprivileged users share the user_u identity.

By convention, role names end with _r, and type names end with _t. A type that belongs to a process is also known as a domain. A role is a name given to a group of process types. Every user is assigned a role, and the role determines which process types (or domains) the user is authorized to use.

To see the security context assigned to a file (or directory), use ls -Z (we’ve trimmed a few columns to fit it on the page):

# ls -Z /var
system_u:object_r:acct_data_t	account
system_u:object_r:var_t	cache
system_u:object_r:var_t	db
system_u:object_r:var_t	empty
system_u:object_r:xserver_log_t gdm
system_u:object_r:var_lib_t	lib
system_u:object_r:var_t	local
system_u:object_r:var_lock_t	lock
system_u:object_r:var_log_t	log
...	...

Notice that in this example, the identity assigned to each file is system_u: That’s a generic identity just like user_u. user_u is shared by nonprivileged subjects, and system_u is assigned to almost every file object. Most files share the same identity (system_u) and role (object_r). The type classifies each file according to its security needs.

When you run a program whose type ends with exec_t, that program causes a transition from your current domain into a new domain. For example, take a peek at the program that you use to change your password (/usr/bin/passwd). The passwd program lets you modify files that are normally protected against nonprivileged users: When you change your password, the new password is (typically) stored in /etc/shadow — a write-protected file. If you look at the context assigned to /usr/bin/ passwd, you see this:

$ ls --scontext /usr/bin/passwd system_u:object_r:passwd_exec_t

/usr/bin/passwd

Notice that the type name ends with _exec_t; that’s your clue that this is a “domain transitioning” program. When you run /usr/bin/passwd, your context changes from user_u:user_r:user_t to user_u: user_r:passwd_t, giving you just enough privileges to modify /etc/shadow and /etc/passwd. If this sounds suspiciously similar to a setuid root program, it is. The important difference is that a domain transition gives you only the privileges required to act on the protected objects that you need, but a setuid root program gives you all privileges.

Given the number of subjects, objects, and access types on a typical Linux system, SELinux security rules are far more complex than the old system.

Disabling or Disarming SELinux

The SELinux kernel can operate in enforcing mode (the default) or in permissive mode:

When you run in enforcing mode, the kernel enforces the security policy that you’ve installed.

When you run in permissive mode, the kernel consults the security policy, but instead of preventing you from doing something that the policy prohibits, the kernel simply logs the violation.

Running in permissive mode will tell you what kind of problems you’re likely to encounter when you switch over to enforcing mode. Policy violations appear at the Linux console and in the system log file (/var/log/dmesg).

By default, Fedora Core 2 boots into enforcing mode. If you want to switch over to permissive mode after your computer has booted, use the following command:

Playing the Right Role 167

# echo “0” > /etc/selinux/enforce

(You need superuser privileges to write to the /etc/ selinux/enforce.) To switch back to enforcing mode, use this command:

# echo “1” > /etc/selinux/enforce

If you want Fedora to run in permissive mode each time you boot, give yourself superuser privileges and type in the following command:

#echo “SELINUX=permissive” > /etc/ sysconfig/selinux

If you prefer to run in enforcing mode after each boot, use this command:

#echo “SELINUX=enforcing” > /etc/ sysconfig/selinux

If you’re sure that you’ll never want to use SELinux on your computer, you can completely disable the kernel extensions with the following command:

#echo “SELINUX=disabled” > /etc/ sysconfig/selinux

The difference between permissive and disabled modes is that in permissive mode, the kernel logs policy violations and labels new files with the appropriate security context. If you disable SELinux completely, new files and directories are created without a security context, and if you ever want to turn SELinux back on, you’ll have to relabel your computer (that is, reapply security contexts). Relabeling can be a lot of work — we recommend running in permissive mode instead of disabling SELinux.

Playing the Right Role

One of the consequences of SELinux is that meremortal users can’t access objects that they may have been able to access before. For example, if your security context is user_u:user_r:user_t and you

run the ps (process status) command, you can’t see privileged processes.

It’s very important to use the correct role when you do system administration work. Some commands work in the staff_r role but produce the wrong results. For example, if you create a new user account while you’re logged in to the sysadm_r role, the home directory for the new account is created with the right context:

# id -Z root:sysadm_r:sysadm_t

#useradd franklin

#ls -Z /home/franklin root:object_r:user_home_dir_t

However, if you create a new account from root’s default role (staff_r), the home directory is labeled incorrectly:

# id -Z root:staff_r:sysadm_t

#useradd franklin

#ls -Z /home/franklin root:object_r:home_root_t

You may be wondering why the identity component of each context is root instead of franklin. The answer is a bit confusing. franklin is a generic user; that is, franklin appears in the Linux user database, but not in the SELinux policy. That means that franklin is not an identity and therefore can’t be assigned as the identity for his home directory. Generic users share a common identity: user_u.

To create a new Linux user with a corresponding identity, use seuseradd instead of useradd:

#newrole -r sysadm_r

#seuseradd -r -m trixie loading new policy...

We’ve thrown another new command at you in this example: newrole. newrole starts a new shell with a different security context. Your identity stays the same, but your role changes to the one you requested. See man newrole for more details.

168 Technique 25: Coping with the SELinux Security System

Finding Out about Your

SELinux Policy

At the time we’re writing this, Fedora Core 2 provides few utilities that you can use to manage SELinux policies. That will change as software vendors and open-source developers learn more about SELinux. For now, you can use the utilities provided by the setools and setools-gui RPM packages (included in the Fedora Core 2 distribution) to find out more about the default policy installed on your system. See Technique 17 for more information about installing RPM packages.

The seinfo command can show you a wealth of information about your policy. For example, to see a list of all identities, give yourself superuser privileges and then type in the following command:

# seinfo --users Users: 5

system_u user_u root freddie trixie

To see the list of roles defined for your system, use this command:

# seinfo --roles Roles: 5

object_r system_r sysadm_r user_r staff_r

root staff_r sysadm_r system_r

freddie staff_r user_r

trixie staff_r

To see the domains that a given role is allowed to assume, use --roles=name --expand:

#seinfo --roles=sysadm_r --expand sysadm_r

null_device_t zero_device_t devtty_t local_login_t remote_login_t

Every object class defines a list of permissions, but it’s probably easier to think of a permission as an action. For example, you can mount, unmount, and remount an object belonging to the filesystem class. To see the permissions (actions) defined for a given class, use this command:

#seinfo --classes=filesystem --expand filesystem

mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget

To see the roles that each identity is allowed to assume, add the --expand option, like this:

# seinfo --users --expand Users: 5

system_u system_r

user_u user_r

Use the following command to see the list of types:

# seinfo --types Types: 291

device_t null_device_t zero_device_t console_device_t memory_device_t

	Finding Out about Your SELinux Policy	169
random_device_t	# seinfo --types=bin_t
urandom_device_t	bin_t
devtty_t	file_type
...	sysadmfile
To see the attributes of a given type, use this	By convention, an object of type bin_t is a file (it has
command:	the attribute file_type), and it’s a system adminis-
	tration file (sysadmfile).