SELinux includes a set of modified daemons and new and modified utilities that have some degree of awareness of the mandatory access controls. Some of these daemons and utilities require their own application configuration files that are related to the policy. This section describes these security-aware applications and their configuration files.
SELinux includes three modified daemon programs:
login, sshd and
crond. Each of these daemons was modified to
transition to an appropriate security context for user processes. The
appropriate security context for a user session or cron job is
determined based on a combination of the security policy and default
configuration files, as described in Section 6.4, or
can optionally be explicitly specified by the user in the case of
login. The transition is performed using the
execve_secure
system call. An explicit
transition is required in order to set the user identity and role
attributes in the security context based on the authenticated user.
The login and sshd daemons
were further modified to relabel the user's terminal device. The
security context for the terminal device is obtained using the
security_change_sid
system call. This call
determines the new terminal context based on the user process context
and the original terminal context. Rules for terminal relabeling can
be specified in the policy configuration via the TE change rules, as
discussed in Section 4.2.4. When the session ends, the
daemons relabel the terminal to its original context.
The crond daemon was further modified to perform
an entrypoint
permission check between the user
process context and the context of the crontab file. This check would
be handled by the kernel if crontab files were executable scripts
rather than configuration files. Since crond
does not directly execute the crontab files, this check is performed
by the daemon to verify that the user process context can be entered
via commands from the crontab file. Domains are defined for the
crontab program to ensure that crontab files are
typed based on the creating user's domain. The permission check is
intended to reduce the risk that a user can cause commands to be
executed by a security context for which the user is not authorized by
tampering with another user's crontab file, even if the user obtains
superuser access.
SELinux includes a number of new utility programs. Simple utilities that can be used to invoke the new system calls are located in the libsecure/test directory and are installed into /usr/local/selinux/bin. Other utility programs can be found within the utils directory and are likewise installed. This section describes the new utilities that are important from the perspective of the policy.
The spasswd collection of utilities are wrapper
programs for the passwd, chsh,
chfn, vipw,
useradd, and userdel programs.
Each of these utilities ensures that the
/etc/passwd and /etc/shadow
files are labeled properly after updates based on the
passwd_context and
shadow_context application configuration files.
The spasswd, schsh, and
schfn utilities enable ordinary users to change
their own information while preventing a process with the Linux root
uid from changing the information for arbitrary users. These three
utilities run in the passwd_t
domain when
executed by any user domain. The svipw and
sadminpasswd utilities enable authorized
administrators to change the information of any user. These programs
run in the passwd_t
domain when executed by the
sysadm_t
domain. The suseradd
and suserdel utilities enable administrators to add
and remove accounts, running in the useradd_t
domain when executed by the sysadm_t
domain.
The newrole utility can be used to transition to a
different role within a user session. It obtains the default domain
for the new role from the default_type
application configuration file described in Section 6.4. Alternatively, the user can explicitly specify
the new domain on the command line. The newrole
program requires the user to reauthenticate to ensure that role
changes only occur with user consent. The authentication is based on
the user identity in the SELinux security context rather than the
unreliable Linux uid. Like the login daemon, the
newrole program also relabels the terminal based on
the new security context. This program runs in the
newrole_t
domain.
The run_init utility can be used to run init
scripts from the same security context as the
init process. This is necessary to ensure that
any processes started by these scripts run with the proper user
identity, role, and domain when the scripts are run manually by an
administrator. The program obtains the security context from the
initrc_context application configuration file
described in Section 6.4. As with
newrole, this program requires the user to
reauthenticate to ensure that such transitions only occur with the
consent of the user. This program runs in the
run_init_t
domain, which can only be entered from
the sysadm_t
domain.
The runas utility can be used to run a program with a specified security context. This utility does not run in its own domain, so the calling domain must have the appropriate permissions to perform the transition to the new security context. This utility is typically used only to transition to a different domain, since user identity and role transitions are limited to privileged domains.
The setfiles and chcon utilities can be used to change the security context of a file. These utilities were discussed in Section 5.2.
The avc_enforcing utility can be used to check whether SELinux is in permissive mode or enforcing mode. The avc_toggle utility can be used to toggle SELinux between permissive and enforcing modes if SELinux was built with the development module option. The development module option is discussed in the installation README and in the kernel configuration help. Only the domains for administrators and for the rc scripts are authorized to use avc_toggle, so only those domains can toggle back into permissive mode once the system is in enforcing mode.
Modified user utilities (e.g. ls,
mkdir, ps,
id, find, etc.) are provided
that permit users to display or specify security contexts. However,
these utilities do not run in their own domains and are not important
from a policy perspective. The only modified utility that is relevant
to the policy is the modified logrotate program.
This program was modified to preserve the security context on log
files when they are rotated. A logrotate_t
domain
was defined for this program and granted the appropriate permissions.
The modified daemons and new utilities described in the preceding sections rely on a set of application configuration files. Examples for each of these files can be found in the utils/appconfig directory in the selinux tree. These files are copied into the /etc/security directory during installation. Each file is discussed below.
The modified daemons ask the security server for the set of legal SIDs for a given user that are reachable from the current process SID (i.e. the SID of the login, sshd, or crond process) and then apply a prioritization based on an optional default_contexts configuration to determine the default SID. Any context in a default_contexts configuration that is not within the set of legal SIDs for the user that can be reached from the current process SID will be ignored.
The default_contexts file defines the default security contexts for user login or ssh sessions and for user cron jobs. Each line of the default_contexts file specifies an entry consisting of a partial context for the system process followed by a list of one or more partial contexts for users in the desired prioritization order. A partial context is a context without a user identity value. Partial contexts are used in the list of user contexts since the user identity can be inferred (it is the user who was authenticated or whose crontab file was read). Partial contexts are used for the system process context to support future use by user-executed programs, like newrole, where the user identity will also be inferred. In the simplest form, an entry identifies the system process context and then provides a single user context to use as the default.
In the example default_contexts file, login and ssh sessions default to user_r:user_t. Users can then use newrole to change to a different role. System cron jobs default to system_r:system_crond_t, while user cron jobs default to user_r:user_crond_t. A derived domain (user_crond_t) is used so that the policy can grant different permissions to user cron jobs than to user sessions.
Each user can also have a $HOME/.default_contexts file that specifies their own preferred default contexts. However, only contexts for which the user is authorized in the policy will be used.
The default_type file defines the default type (domain) for each role. Each line specifies a role:type pair, and the appropriate type is selected by matching the role field. This file is used by the modified login program to automatically provide a default domain when the user selects a role, and it is used by the newrole program to automatically provide a new domain based on the new role. If no entry is specified, then the user must explicitly specify a domain.
The initrc_context file defines the security context for running /etc/rc.d scripts via the run_init program. It consists of a single line specifying the proper security context. The run_init program transitions to this security context and then runs the specified script. This ensures that the scripts are executed from the same context as when they are run by init.
The passwd_context and shadow_context files define the context to be assigned to the /etc/passwd and /etc/shadow files. These files are used by the spasswd collection of utilities to relabel /etc/passwd and /etc/shadow after updating these two files so that they retain the correct context.