| SELinux is largely transparent to ordinary system users and presents system administrators with few complications. This section describes the handful of issues that users and administrators need to be aware of when using and administering an SELinux system. The issues fall into the following broad categories: 4.3.1 Entering a Role Recall that, as explained in Chapter 2, SELinux users have one or more associated roles and, at any time, are bound to exactly one of these. Users are initially bound to a role at login time. Thereafter, a user can issue a special command to replace this binding with a binding to any role for which the user is authorized. System administrators may use this command to transition back and forth between the staff_r and sysadm_r roles. Otherwise, role transitions are relatively rare. The standard SELinux security policy defines four roles: -
- staff_r
-
Used for users permitted to enter the sysadm_r role -
- sysadm_r
-
Used for the system administrator -
- system_r
-
Used for system processes and objects -
- user_r
-
Used for ordinary users  | The flexibility of SELinux makes it possible for SELinux administrators to define additional roles. However, few administrators find any need to do so. The four canonical roles are the only roles found on most SELinux systems. | |
When a user logs into an SELinux system, the system will either: If the user is authorized to enter only one role, no menu is presented. Instead, the user is automatically placed in the role. Since the su - command initiates a login shell, the menu may also appear when that command is issued. Fedora Core works this way, but other SELinux implementations may not. Here's a typical example of the menu: $ su - Password: Your default context is root:sysadm_r:sysadm_t. Do you want to choose a different one? [n] y [1] root:staff_r:staff_t Enter number of choice: 1
When the menu appears, it displays the default context and asks the user whether another context is preferred. If the user responds affirmatively, the menu lists the contexts for which the user is authorized, associating a number with each context. By typing the number associated with a listed context, the user can enter that context. 4.3.1.1 Changing roles After login, a user may wish to enter a role other than the one assigned at login. For instance, a user who is authorized to enter the sysadm_r role may wish to do so in order to issue one or more commands that are restricted to system administrators. To enter a new role, a user issues the newrole command. The simplest and most common form of the newrole command has this syntax: newrole -r role
where role identifies the role to be entered. If the user is not authorized to enter the role, the command fails. Otherwise, the command creates a new shell in a context labeled with the user's identity, the new role, and a default type derived from the new role. However, before the shell is instantiated , the user is prompted to confirm her identity by entering her Linux password. | | Please bear in mind that only users who are associated with the staff_r role can transition to the sysadm_r role by issuing the newrole command. Your SELinux user configuration determines whether a user is associated with the staff_r or user_r role. Also, if you're using Fedora Core, recall that its su command has been modified to automatically transition to the sysadm_r role when you become the root user. Other implementations of SELinux do not currently share this characteristic. | |
Here's a typical usage of the newrole command. Suppose you are a system administrator currently logged in to the staff_r:staff_t security context rather than the sysadm_r:sysadm_r security context. You need to add a new user, a task that requires you to enter the sysadm_r:sysadm_t security context. Here's how you might do so: # id -Z root:staff_r:staff_t # newrole -r sysadm_r Authenticating root. Password: # id -Z root:sysadm_r:sysadm_t
The id -Z command, explained in the following section, reports the user's security context. You don't need to issue the id command when you change roles, but doing so makes it possible to verify that you have indeed left your original role and entered the desired one. As you can see in the example, the newrole command changed the role from staff_r to sysadm_r . The full form of the newrole command is: newrole [[-r--role] ROLE ] [[-t--type] TYPE ] [-- [ ARGS ]...]
The -t option, which can also be specified as ”type , enables a type to be explicitly specified rather than inferred from the role. The option also enables transitioning to a new type without changing role, though this is seldom done. The ARGS arguments let the user specify arguments to be passed to the new shell. 4.3.2 Viewing Security Contexts SELinux provides modified versions of several familiar commands, extending them with the capability of reporting security contexts. The commands include: -
- id
-
View the user context. -
- ls
-
View a file context. -
- ps
-
View a process context. The following subsections explain how to use the modified commands. 4.3.2.1 Viewing the user security context Under Linux, the id command reports real and effective user IDs and group IDs. Under SELinux, the id command has been modified to also report the security context of the current user: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t
The command has also been modified to include a special -Z option that causes the command's output to include the security context of the current user: # id -Z root:sysadm_r:sysadm_t
Although the id command continues to support an argument specifying the name of the user to be reported , the security context is printed only when this argument is omitted. The command is capable of reporting the security context of only the current user. For instance, suppose you issue the following command: # id bill uid=1001(bill) gid=100(users) groups=100(users),10(wheel)
The command doesn't report the security context associated with the user bill . 4.3.2.2 Viewing a file security context Under Linux, the ls command lists directory contents. Under SELinux, the ls command has been modified to also report the security context of directory contents. This behavior is triggered by including one of the following options: -
- ”context
-
Prints a partial file context designed to generally fit on a single line. -
- ”lcontext
-
Prints the full file context. -
- ”scontext
-
Prints only the file context. -
- -Z
-
Same result as ”context . Sample output of the ls command follows : # ls -l /etc/hosts -rw-r--r-- 2 root root 191 Apr 18 20:09 /etc/hosts # ls --context /etc/hosts -rw-r--r--+ root root system_u:object_r:etc_t /etc/hosts # ls --lcontext /etc/hosts -rw-r--r-- 2 system_u:object_r:etc_t root root 191 Apr 18 20:09 /etc/hosts # ls --scontext /etc/hosts system_u:object_r:etc_t /etc/hosts # ls -Z /etc/hosts -rw-r--r--+ root root system_u:object_r:etc_t /etc/hosts
4.3.2.3 Viewing a process security context Under Linux, the ps command gives a snapshot of the current process or a specified process or processes. Under SELinux, the ps command has been modified to also report the security context of processes. This behavior is specified by use of the -Z option or ”context option: # ps PID TTY TIME CMD 8433 pts/1 00:00:00 su 8436 pts/1 00:00:00 bash 8800 pts/1 00:00:00 ps # ps -Z PID CONTEXT COMMAND 8433 bill:sysadm_r:sysadm_su_t su - 8436 root:sysadm_r:sysadm_t -bash 8801 root:sysadm_r:sysadm_t ps -Z # ps --context PID CONTEXT COMMAND 8433 bill:sysadm_r:sysadm_su_t su - 8436 root:sysadm_r:sysadm_t -bash 8803 root:sysadm_r:sysadm_t ps --context
As you can see, either option has the same result. You can use the modified ps command to snapshot processes other than the current process, and can use any of the options or arguments supported by the standard Linux ps command. For instance: # ps -Z 1 PID CONTEXT COMMAND 1 system_u:system_r:init_t init [2]
4.3.3 Adding Users Under SELinux, users' home directories are labeled with the special security context user_home_dir_t . When you create a new user account by using the useradd command, SELinux automatically labels the user's home directory with the proper security context. However, before creating a new user account, you should first enter the sysadm_r role so that you have the permissions necessary to set the security context. Here's an example showing how a user account is added, and the security context assigned to the new user's home directory: # id -Z root:staff_r:staff_t # newrole -r sysadm_r Authenticating root. Password: # id -Z root:sysadm_r:sysadm_t # useradd -c "test user" -m -d /home/testuser -g users -s /bin/bash testuser # finger testuser Login: testuser Name: test user Directory: /home/testuser Shell: /bin/bash Never logged in. No mail. No Plan. # ls -ld -Z /home/testuser/ drwx------+ testuser users root:object_r:user_home_dir_t /home/testuser/
4.3.3.1 Associating a user with a nondefault role By default, users are associated with the SELinux role user_r , which is appropriate for users who are not authorized to enter the sysadm_r role. If you wish to authorize the user to enter the sysadm_r role, you must: -
Edit the src/policy/users file. -
Recompile the security policy. -
Load the generated binary policy file into the kernel. You can edit the src/policy/users file with your preferred text editor, such as vi . Add a line having the following form to the file: user username roles { staff_r sysadm_r };
where username is the name of the user account that you want to authorize to enter the sysadm_r role. To recompile and load the security policy, make /etc/security/selinux/src/policy the current working directory and issue the following command: make reload
4.3.3.2 How default roles are assigned As explained in Chapter 5, the src/policy/appconfig/default_contexts file specifies default roles for user logins, SSH sessions, and cron jobs. The file is a simple text file consisting of two columns . The first column specifies a partial context (the role and domain) for the system process ( login , sshd , or crond ). For instance, the fourth line, which refers to the sshd_t domain, pertains to the sshd process. The second column specifies one or more security contexts, each of the form user:role:type . A typical default_contexts file follows: system_r:sulogin_t sysadm_r:sysadm_t system_r:local_login_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t system_r:remote_login_t user_r:user_t staff_r:staff_t system_r:sshd_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t system_r:crond_t user_r:user_crond_t staff_r:staff_crond_t sysadm_r:sysadm_crond_t system_r:system_crond_t mailman_r:user_crond_t system_r:xdm_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t staff_r:staff_su_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t sysadm_r:sysadm_su_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t user_r:user_su_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t sysadm_r:sudo_t sysadm_r:sysadm_t staff_r:sudo_t sysadm_r:sysadm_t staff_r:staff_t user_r:sudo_t sysadm_r:sysadm_t user_r:user_t
When SELinux must determine the default role for a login, session, or job, it consults the default_contexts file and selects the first line matching the partial context of the system process. SELinux then assigns the first security context that the user is permitted to enter; or, in the case of an interactive shell, SELinux may present a menu prompting the user to choose from among the available contexts. For instance, during a local login, SELinux consults the line: system_r:local_login_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t
This line tells SELinux to present a menu enabling the user to select from among the following security contexts: -
staff_r:staff_t -
user_r:user_t -
sysadm_r:sysadm_t However, SELinux won't present a given menu item unless the user is authorized to enter the related security context. An ordinary user can enter only the user_r:user_t context and thus no menu is presented. | | If, as an ordinary user, you find that the default roles provided by the default_contexts file fail to meet your needs, you can create your own default_contexts file, ~/default_contexts . However, the file merely specifies your preferences; it does not permit you to enter security contexts other than those authorized by the system administrator. | |
4.3.3.3 Setting user passwords When setting user passwords, it's generally convenient to use the standard Linux passwd command. Under SELinux, this command has been modified to preserve the security contexts associated with the /etc/shadow file. If you use vipw , vi , or some other means to modify /etc/passwd , /etc/group , or /etc/shadow , you'll likely remove the security context labeling the file, which will make the file inaccessible. If you discover that you've disrupted the file label, you can repair the damage by using the restorecon command, described earlier in this chapter. For instance, to repair the file label associated with the /etc/shadow file, issue the command: restorecon /etc/shadow
| | If the restorecon command is not available in your SELinux implementation, you can use the setfiles command or one of the other file labeling commands explained earlier in this chapter. | |
4.3.4 Starting and Controlling Daemons The init process generally starts several daemons when the system is booted or the current runlevel is changed. To do so, init uses init scripts that reside in the /etc/init.d directory. The init process ensures that such scripts are started in a proper security context by referring to the src/policy/appconfig/initrc_context file. When the system administrator manually starts an init script, the script must similarly be started in a proper security context. Establishing a proper security context is simplified by the run_init command, which runs an init script or program in the proper context. The run_init command has this form: run_init script [[ arg ]...]
where script is a path associated with the init script to be started and arg (which can be multiple arguments) optionally provides the init script with run arguments. For example, to start the NTP daemon via its init script, /etc/init.d/ntpd , issue the command: run_init /etc/init.d/ntpd start
Daemons started without using the run_init command are likely to be run in an incorrect security context and therefore fail. | | By default, Fedora Core 2 allows a role transition from sysadm_r to system_r , the role used by init . Therefore, unless you've specially configured Fedora Core 2 to disable this transition, it's not necessary to invoke the run_init command explicitly. | |
4.3.4.1 Starting non-init daemons and programs Just as an init script may fail when started in an inappropriate security context, other programs may require that they be started in a specific context. To facilitate starting such programs, SELinux provides the run_con command, which lets you specify the security context in which a program runs. The run_con command has the following form: runcon [-t TYPE ] [-u USER ] [-r ROLE ] COMMAND [ ARGS ...]
where TYPE , USER , and ROLE specify the security context under which the program should run, and COMMAND and ARGS specify the program to be run and its arguments. For example, suppose the cron daemon has died and you want to restart it. The easiest way to do so is by using the run_init command or, on Fedora Core, the service command. But, suppose you tried to start the daemon like this: # /usr/sbin/crond
The result will not be felicitous because the cron daemon will execute in the security context root:system_r:system_t , whereas it should execute in the security context system_u:system_r:crond_t . As a result, if you check your log files, you'll find that the cron daemon is unable to properly start cron jobs. The run_con command enables you to start cron in the proper context. To do so, simply issue the command: runcon -u system_u -r system_r -t crond_t /usr/sbin/crond
An alternative form of the command is convenient when all the components of the security context are specified, as in the example: runcon CONTEXT COMMAND [ args ...]
The CONTEXT argument consists of a security context that includes a user identity, role, and type, specified in that order ”for example, system_u:system_r:crond_t . To use this form of the run_con command to run the command run_con in the security context system_u:system_r:crond_t , issue the command: runcon system_u:system_r:crond_t /usr/sbin/crond
| 