SELinux [Electronic resources] نسخه متنی

4.3 Routine SELinux System Use and Administration

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

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:

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.

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 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 orderfor 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