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:
Entering a role
Viewing security contexts
Adding users and groups
Starting and controlling daemons
Tuning SELinux
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:
Tip
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:
Automatically assign a default role.
Present a convenient menu that enables the user to choose from the roles the user is authorized to enter.
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.
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.
Tip
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.
SELinux provides modified versions of several familiar commands, extending them with the capability of reporting security contexts. The commands include:
The following subsections explain how to use the modified commands.
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
.
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:
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
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]
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/
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:
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
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.
Tip
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.
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
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_initscript
[[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.
Tip
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.
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 [-tTYPE
] [-uUSER
] [-rROLE
]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:
runconCONTEXT
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
Get SELinux now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.