لطفا منتظر باشید ...
4.2 Controlling SELinux
Controlling SELinux entails three primary operations:
Switching the SELinux mode
Loading a security policy
Labeling files
The following subsections explain how to perform these operations.
The available commands and the associated command options provided by
a given implementation of SELinux may differ a bit from those
described in the following subsections. When you encounter such
differences, you should check your system man pages and other
available documentation to understand the operation of your system.
4.2.1 Switching Modes
If
your Linux kernel was compiled with the
NSA SELinux Development support option, you can
specify the SELinux operating mode that should be entered when your
SELinux system is booted. And, unless the SELinux security policy
specifies otherwise, you can dynamically change the operating mode of
a running SELinux system. Additionally, if your Linux kernel was
compiled with the NSA SELinux boot
parameter option, you can entirely disable SELinux via a
boot parameter. The following subsections explain how to do so.
The initial operating mode of an SELinux system can be
set via the boot parameter enforcing
. To boot the
system into enforcing mode, assign this boot
parameter the value 1
; to boot the system into
permissive mode, assign this boot
parameter the value 0
.
If you use GRUB to boot your system and want the
system to automatically boot into enforcing mode, you might specify a
kernel
directive such as the following in
your GRUB configuration file (generally,
/boot/grub/grub.conf):
kernel /vmlinuz-2.6.4-1.305 ro root=LABEL=/ enforcing=1
If you use LILO to boot your system and want the
system to automatically enter permissive mode after booting, you
might specify an append
directive such as the following in
your LILO configuration file (generally,
/etc/lilo.conf):
append="enforcing=0"
Whether you use GRUB or LILO, you may find it convenient to configure
two boot configurations: one booting into enforcing mode and another
booting into permissive mode. Doing so makes it easy to interactively
choose the SELinux mode each time the system is booted.
GRUB optionally supports interactive editing of boot configurations.
If you use GRUB, you may find it convenient to specify only an
enforcing-mode boot configuration. When you want to boot the system
into permissive mode, you can interactively edit the
kernel
directive to specify the value 0 for the
enforcing
option.
If you specify multiple boot configurations, and your system resides
in a hostile environment, be sure to configure the boot manager to
load the enforcing-mode configuration by default; otherwise, if
someone untrained in SELinux or too much in a hurry reboots your
system, it will enter permissive mode when booted and may be
compromised.
To ameliorate the difficulty of
troubleshooting
an inaccurate or incomplete TE file in enforcing mode, you can
install two kernels on your system: one compiled without the
NSA SELinux Development
support option and one compiled with the option. To help
ensure that the system remains secure under normal circumstances,
specify the configuration without the NSA SELinux
Development support option as the default boot
configuration. When you need to troubleshoot the system, you can
reboot the system using the alternate kernel compiled with the
NSA SELinux Development support option.
If youre especially concerned about security, you
may feel that including a kernel capable of permissive mode in your
systems boot configuration is too risky. In that
case, you can prepare a boot disk or boot CD containing a permissive
kernel and boot the system from your external media when
troubleshooting is necessary.
You may find it impractical to reboot your system to perform
troubleshooting. Indeed, a popular Linux mantra has it that
"rebooting is only for installing new
hardware." In this case, you may find it necessary
to maintain a clone of your production system, so that you can verify
that activities such as installation of a new software package will
work correctly and not interfere with system operation.
Unless your SELinux security policy or the absence of the
NSA SELinux Development support option dictate
otherwise, you can set the operating
mode of a running SELinux system dynamically. To ensure system
integrity, the SELinux security policy prohibits nonprivileged
users from dynamically setting the SELinux operating mode. Even the
root user cannot do so unless operating within the
sysadm_r
role. The section of this chapter titled
"Changing Roles" explains user
roles and how to enter the sysadm_r
role. If you
possess the necessary privileges, you can dynamically set the SELinux
operating mode either by manipulating a file within the
/selinux
filesystem or by issuing a special command.
The /selinux filesystem is a
virtual
filesystem resembling the familiar /proc or
/sys filesystem. That is, it looks just like a
filesystem but doesnt reside on a hard drive or
other physical media. Instead, its automatically
generated by the kernel. The file
/selinux/enforce indicates the current SELinux
mode. Manipulating the file changes the current SELinux mode.
You can determine the current SELinux mode by issuing the command:
cat /selinux/enforce
The value that is displayed indicates the current mode: the value
0
indicates permissive mode and
1
indicates enforcing mode.
To enter enforcing mode, issue the command:
echo "1" > /selinux/enforce
Similarly, to enter permissive mode, issue the command:
echo "0" > /selinux/enforce
Many users find it inconvenient to directly access or modify the
contents of the /selinux/enforce file. SELinux
implementations provide commands that enable a properly privileged
user to determine, or set, the current SELinux mode. In earlier
SELinux releases, the command used to determine the current SELinux
mode was avc_enforcing
.
Issuing this command printed the value
"permissive" or
"enforcing" according to the
current SELinux mode. And, generally, the command
avc_toggle
was
available to toggle the current SELinux mode, changing from
permissive to enforcement or vice versa.
Under the current SELinux release, which breaks with tradition, the
command getenforce reports
the current SELinux mode as
"permissive" or
"enforcing." The
setenforce command
changes the current SELinux mode. However, unlike the
avc_toggle
command, the
setenforce command does not toggle the current
mode. Instead, the setenforce command takes an
argument that specifies the desired SELinux mode:
0
for permissive mode and 1
for
enforcing mode. For instance, to enter permissive mode under Fedora
Core 2, you issue the command:
setenforce 0
If a Linux kernel was compiled with the
NSA SELinux boot
parameter option, its possible to
completely disable SELinux at boot time. To do so, specify the boot
parameter and value selinux=0
in the boot
configuration, or interactively specify this parameter-value pair in
response to a boot prompt or menu.
By disabling SELinux, you preclude it from prohibiting actions based
on its security policy and from generating log entries. You also
avoid the overhead entailed by SELinux itself, which some estimate
consumes roughly seven percent of CPU resources. In essence, your
system operates as though it were using a non-SELinux kernel.
You may find it convenient to disable SELinux when SELinux is
operating improperly or entirely failing to operate. Booting in
disabled mode may enable you to troubleshoot and repair the problem.
However, when SELinux is disabled, its not
available to write appropriate file labels for newly created files,
including files replaced after editing. Consequently, your system
almost certainly will not operate correctly if you subsequently boot
with SELinux enabled. To avoid this problem, you must relabel the
filesystemsor at least all new filesbefore booting the
system with SELinux enabled. The section of this chapter titled
"Labeling Files" explains how to do
so.
4.2.2 Loading the SELinux Security Policy
If you
configure your system to boot into
enforcing mode, it will automatically load the SELinux security
policy at boot time. However, you may find it necessary or convenient
to load the SELinux security policy at another time. For instance,
you may modify the security policy and desire to replace the current
security policy with the modified policy. This section explains how
to load the security policy and perform several related operations.
As explained in Chapter 5, the
/etc/security/selinux/src/policy directory
contains a Makefile and
related files that enable a system administrator to manipulate the
security policy. SELinux prevents ordinary users from manipulating
the security policy; only the root user in the
sysadm_r
role can manipulate the policy.
If your system does not include the src/policy
directory and the Makefile that resides there,
its likely that youve installed
SELinux only partially. For instance, under Fedora Core 2,
its likely that you havent
installed the checkpolicy and
policy-sources RPM packages.
You may choose to delete the policy source files from your system.
Doing so may complicate the work of an intruder seeking a way to
circumvent the SELinux security policy.
The Makefile
supports five
operations related to the security policy. In addition, it supports
one operation related to file labeling, which is explained in the
following section. Table 4-1 summarizes the
operations supported by the Makefile, which are
known as targets.
Table 4-1. Policy Makefile targets
Make target
Compiles the policy from source?
Installs the policy?
Loads or reloads the policy?
policy
Yes
No
No
install
Yes
Yes
No
load
Yes
Yes
Yes
reload
Yes
Yes
Yes
relabel
No
No
No
If youre not familiar with
Makefiles and their use, I suggest that you
consult
Managing
Projects with Make (OReilly).
The three steps that can be performed through the
Makefile are:
Compiles the policy from source
Checks the syntax of the policy source files and verifies that
no policy constraints are violated.
Installs the policy
Creates the binary SELinux policy.
Loads or reloads the policy
Currently, the load
and
reload
targets work the same way. Each loads the
binary SELinux policy into the running kernel and begins using it to
make security decisions.
To use the Makefile to perform a supported
operation, follow this procedure:
Be sure your current role is sysadm_r
. The section
"Routine SELinux System Use and
Administration" of this chapter explains how to do
so:
#id -Z
root:staff_r:staff_t#newrole -r sysadm_r
Authenticating root.
Password:
#id -Z
root:sysadm_r:sysadm_t
If youre not logged in as the root user, issue the
su command to become the root user:
su -
Fedora Core automatically transitions you to the
sysadm_r
role when you issue the
su command. If youre not using
Fedora Core, you must explicitly transition to the
sysadm_r
role:
newrole -r sysadm_r
Change the current working directory to
/etc/security/selinux/src/policy:
cd /etc/security/selinux/src/policy
Invoke the desired operation:
make target
where target
is the desired operation. For
instance, to reload the security policy, issue the command:
make reload
Observe any error messages that appear on the console and take
appropriate action.
Depending on the target you specify, the
Makefile invokes one or both of the following
SELinux utilities:
checkpolicy
The SELinux policy compiler
load_policy
A utility that loads the SELinux binary policy into the running kernel
Its generally best to use the
Makefile to perform policy-related operations.
But, you may find it useful or necessary to understand how the
Makefile does its work. The following sections
explain the main utilities invoked by the
Makefile: checkpolicy and
load_policy.
The
SELinux policy compiler
checkpolicy reads an SELinux policy
source file and creates a
binary policy file. In preparation for
policy compilation, the SELinux Makefile
provides the compiler with a single policy source file that includes
all the installed TE files and other policy source files. The
Makefile also expands M4 macros contained in
those files.
The SELinux policy compiler has the following syntax:
checkpolicy [-b] [-c policyvers
] [-d] [-o output_file
] [input_file
]
The -b option instructs the policy compiler to
read a binary policy file (contained in a file named
policy) rather than a source policy file. This
flag is rarely used.
The -c flag specifies the policy version number.
If the flag is omitted, the latest policy version is assumed.
The -d option instructs the policy compiler to
enter debug mode after it loads the policy.
The -o option specifies the name of the binary
policy file that the compiler will write.
The input_file
argument specifies the name of the
policy source file that the compiler will process. If the argument is
omitted, the compiler reads the policy.conf file
(unless the -b option appears, in which case the
compiler reads the binary policy file named
policy).
For more information on the policy compiler and the compilation
process, see the paper "Configuring the SELinux
Policy," by Stephen Smalley, available at http://www.nsa.gov/selinux/info/docs.cfm.
The load_policy
utility
reads a binary policy file, the name of which is specified as a
command argument, and loads the policy into the running kernel. The
utility provides no other arguments or options.
4.2.3 Labeling Filesystems and Files
As Chapter 3, SELinux requires that files be labeled
with extended attributes indicating their security context. Available
filesystems are typically labeled when SELinux is installed.
Its not routinely necessary to relabel filesystems
and files after installation. However, it sometimes is necessary to
do so. For instance, installation of a new filesystem may require the
filesystem to be labeled. Or booting a system from a non-SELinux
kernel may result in the creation of unlabeled files or the removal
of labels from labeled files. Under such circumstances, you can use
the Makefile in
/etc/security/selinux/src/policy to label or
relabel all available filesystems. Alternatively, you can use any of
several commands to label or relabel just the filesystems or files
that lack proper labels. This section explains how to perform these
operations.
Some filesystem types do not support the extended attributes used to
store file context labels. The
src/policy/genfs_contexts file provides default
contexts for files residing in such filesystems.
Depending on the size of the systems hard drives
and the number of files they store, the relabeling operation may
require many minutes, perhaps more than an hour. When only a few
files require relabeling, its inefficient to
relabel by using the Makefile. In such cases,
its better to perform the relabeling by using an
SELinux utility. The next section explains how to do so.
To
relabel all available filesystems
by using the src/policy
Makefile, follow this procedure:
Be sure your current role is sysadm_r
. The section
"Routine SELinux System Use and
Administration" of this chapter explains how to do
so:
#id -Z
root:staff_r:staff_t
#newrole -r sysadm_r
Authenticating root.
Password:
#id -Z
root:sysadm_r:sysadm_t
If youre not logged in as the root user, issue the
su command to become the root user:
su -
Fedora Core
automatically transitions you to the sysadm_r
role
when you issue the su command. If
youre not using Fedora Core, you must explicitly
transition to the sysadm_r
role:
newrole -r sysadm_r
Change the current working directory to
/etc/security/selinux/src/policy:
cd /etc/security/selinux/src/policy
Invoke the relabel
operation:
make relabel
Observe any error messages that appear on the console and take
appropriate action.
SELinux provides several utilities that report or manipulate file
labels. The utilities differ primarily in whether they operate on
files or filesystems and whether they label by using a fixed,
specified context or by using a specification file. One or another of
the utilities is apt to be more convenient in any particular
situation. The available utilities include:
/usr/bin/chcon
Labels one or more files with a specified security context
/sbin/fixfiles
Labels all available filesystems according to the contents of the
standard specification file,
src/policy/file_contexts/file_contexts
/sbin/restorecon
Labels one or more files according to the contents of the standard
specification file,
src/policy/file_contexts/file_contexts
/usr/sbin/setfiles
Labels one or more files or filesystems according to the contents of
a specification file
The following subsections explain each utility in more detail.
The chcon utility labels one or more
filesystems with a security context. The command has two forms. The
first form is used to label a file with a specified security context.
The second form is used to label a file with the security context
associated with a specified reference file.
The first form has this syntax:
chcon [options
] context
path
...
For the moment, please ignore the command options. The remaining
arguments represent a security context and one or more paths to be
labeled or relabeled. For example, to set the security context of the
files /etc/hosts and
/etc/hosts.allow to
system_u:object_r:etc_t, issue the command:
chcon system_u:object_r:etc_t /etc/hosts /etc/hosts.allow
The second form has this syntax:
chcon [options
] --reference=rfile
path...
The security context associated with the reference file,
rfile
, is used to label or relabel the
specified paths. For example, to set the security context of the
files /etc/hosts.allow and
/etc/hosts.deny to the current security context
of the file /etc/hosts, issue the command:
chcon --reference=/etc/hosts /etc/hosts.allow /etc/hosts.deny
In addition, the chcon utility supports several
options:
-c, changes
Print a message for each change made.
-h, no-dereference
Operate on symbolic links instead of files they reference.
-f, silent, quiet
Suppress noncritical error messages.
-R, recursive
Change files and directories recursively.
-r, role ROLE
Set role ROLE in the target security context.
-t, type TYPE
Set type TYPE in the target security context.
-u, user USER
Set user USER in the target security context.
-v, verbose
Print a message for each file processed.
help
Print a help message and then exit.
version
Print version information and then exit.
The fixfiles utility labels all available
filesystems according to the contents of the standard specification
file, src/policy/file_contexts/file_contexts.
The form of the command is:
fixfiles [check | restore | relabel]
That is, exactly one of the following arguments must appear:
check
Show any incorrect file labels, but do not change any file labels.
restore
Change the labels of any incorrectly labeled files.
relabel
Relabel all available filesystems.
For example, to check the file labels on all mounted filesystems,
issue the command:
fixfiles check
The restorecon
utility labels one or more files according to the contents of the
standard specification file,
src/policy/file_contexts/file_contexts. The
command has the following form:
restorecon [-n] [-v] path
...
One or more path names must be specified as arguments. For example,
to label the file /etc/hosts according to the
standard specification file, issue the command:
restorecon /etc/hosts
The command options have the following meanings:
-n
Do not change any file labels; merely print the changes that would be
made.
-v
Show changes to file labels.
Whereas the fixfiles
utility labels all available
filesystems, the setfiles utility labels one or
more specified filesystems. The command has the following form:
setfiles [options] spec_file
path
...
The spec_file
argument specifies the file
containing the specifications used to determine file labels. It has
the same form as the FC files, which will be described in Chapter 5. The path
argument specifies the files to be labeled. For example, to label the
/etc/hosts file using the specifications
contained in the file
src/policy/file_contexts/file_contexts, issue
the command:
setfiles src/policy/file_contexts/file_contexts /etc/hosts
The available command options include:
-d
Show the specification that matched each file.
-n
Dont change any file labels.
-q
Suppress noncritical messages.
-s
Take a list of files from standard input rather than use a pathname
on the command line.
-v
Show changes in file labels if type or role is changed.
-vv
Show changes in file labels if type, role, or user is changed.
-W
Print warnings about specification entries that have no matching
files.
4.2.4 Tuning Fedora Core 2 SELinux
Because of the
SELinux policy language and Flask architecture, SELinux is highly
flexible. A system administrator can tailoror entirely
replacethe standard SELinux security policy with a customized
policy that better suits the local environment. However, some
implementations of SELinux provide very simple means for tailoring
policy operation. In particular, the Fedora Core 2 implementation of
SELinux provides two convenient ways of tailoring SELinux operation:
Macros
Policy Booleans
The following subsections describe these means. If
youre using an SELinux implementation other than
that associated with Fedora Core 2, you may find that your
implementation provides similar features, though perhaps in a
different way. And even if your SELinux implementation entirely lacks
features like those described in the upcoming sections, the sections
may suggest useful ways in which to modify your SELinux security
policy. So youre likely to find it worthwhile to
read the sections, even though they deal specifically with the Fedora
Core 2 SELinux implementation.
The file
src/policy/tunable.te defines two to three dozen
M4 macros that you can use to tailor the
operation of SELinux. Doing so is simple: you merely comment or
uncomment a macro definition.
M4 does not use the hash mark (#) to denote comments, as many other
Linux programs do. Instead, M4 prefixes comments with the characters
dnl
("do not list"), followed by a
space. If youve configured Sendmail, which uses
M4, youre
familiar with M4s rather odd convention.
Table 4-2 summarizes the macros defined in
tunable.te.
Table 4-2. Policy macros
Policy macro
Active by default?
Description
allow_user_direct_mouse
Yes
Allow regular users direct access to the mouse device file (otherwise
allow only the X server to do so).
allow_user_dmesg
Yes
Allow users to run the dmesg
command
allow_user_tcp_server
Yes
Allow users to run TCP servers (bind to ports and accept connection
from the same domain and outside users). Disabling this Boolean
forces FTP passive mode and may affect other protocols (including IRC
if single_userdomain
is defined).
allow_xserver_home_fonts
Yes
Allow X server to check for fonts in ~/.gnome or
~/.kde.
allow_ypbind
Yes
Allow ypbind
to run with NIS.
direct_sysadm_daemon
Yes
Allow sysadm_t
to start daemons directly.
ftp_home_dir
No
Allow FTP to read/write files in user home directories.
ftpd_is_daemon
Yes
Allow FTP to run from inetd
instead of as a
stand-alone daemon.
hide_broken_symptoms
No
Adds dontaudit
rules for broken polices that are
not security risks.
nfs_export_all_ro
No
Allow reading on any filesystem.
nfs_export_all_rw
Yes
Allow read/write/create on any filesystem.
nfs_home_dirs
Yes
Allow NFS home directories.
nscd_all_connect
Yes
Allow all domains to access NSCD.
read_default_t
Yes
Allow ordinary users to read any file having type
default_t
.
readhome
Yes
Allow Mozilla to read files in the user home directory.
run_ssh_inetd
No
Allow SSH to run from inetd
instead of as a daemon.
secure_levels
No
Allow only administrator to log in at the console and forbid direct
access to disk devices.
single_userdomain
No
Make processes other than newrole and
su run by a user domain stay in the same user
domain.
ssh_sysadm_login
Yes
Allow SSH logins to the sysadm_r:sysadm_t
security
context; otherwise, remote SSH users cannot enter this context.
staff_read_sysadm_file
No
Allow staff_r
users to search the system
administrators home directory (generally
/root) and read its files.
unlimitedServices
Yes
Allow processes under initrc
and
xinetd
to run with all privileges.
unlimitedUsers
No
Allow users to have full access.
unrestricted_admin
Yes
Allow sysadm_t
to do almost everything.
use_games
Yes
Allow users to run games.
user_can_mount
Yes
Allow users to execute mount command.
user_canbe_sysadm
Yes
Allow normal users to enter sysadm_r
role.
user_net_control
Yes
Allow users to control network interfaces (also needs
USERCTL
=true).
user_rw_noexattrfile
Yes
Allow users to read/write noextattrfile
(FAT,
CDROM, FLOPPY).
writehome
Yes
Allow Mozilla to write files in the user home directory.
xdm_sysadm_login
Yes
Allow xdm
logins as
sysadm_r:sysadm_t
.
The description of tunable.te macros given in
Table 4-2 is based on the Test 2 release of Fedora
Core 2. Its possibleeven likelythat
the contents of the file will differ in subsequent releases.
To tailor the security policy using tunable.te,
follow this procedure:
Make the current working directory
/etc/security/selinux/src/policy.
Using a text editor, comment or uncomment macros in
tunable.te, by adding or deleting the
dnl token.
Compile the policy sources and load a revised binary policy by
issuing the command make reload
.
Fedora Core 2
introduces Policy
Booleans (generally referred to as simply
Booleans), a new SELinux feature that enables
modification of a running SELinux security policy. Booleans are
true-false values that can be tested by security policy rules. The
unique aspect of Booleans is that special commands can query and
change their values at any time. The commands, of course, are
available only to system administrators.
At the time of writing, the Fedora Core 2 security policy defines
only one Boolean:
user_ping
. The value of the
user_ping
Boolean specifies whether ordinary users
are permitted to use the ping command.
Admittedly, this Boolean enables a rather trivial policy tweak.
However, its likely that subsequent releases of
Fedora Core 2 and releases of other SELinux implementations will
include additional Booleans.
Two commands are used in working with Booleans:
change_bool
Changes
the value of a Boolean.
show_bools
Prints
all available Booleans and their values.
The change_bool command has the following form:
change_bool boolean
[0|1]
where boolean
is the name of the Boolean
whose value is being set. The value 0 stands for
false
and 1 stands for true
.
For example, to set the value of the user_ping
Boolean to false
, issue the command:
change_bool user_ping 0
The show_bools command, which reports the value
of available Booleans, requires no options or arguments. Typical
output of show_bools follows:
#show_bools
user_ping --> active: 0 pending: 0
Notice that the output of the show_bools command
distinguishes two values for each listed Boolean: the
active value and the pending
value. When setting Boolean values via
change_bool, this distinction is not important.
Internally, SELinux allows revised Boolean values to be designated in
a way that enables the system administrator to cause the changes to
several different values to take effect simultaneously. However, the
change_bool command immediately commits changes
to Booleans. Therefore, when using the
change_bool command to set Boolean values, the
active and pending values should always be the same.
Rather
than use the
change_bool command to set the value of a
Boolean, you can manipulate nodes within the
/selinux/boolean directory of the
/selinux filesystem. The names of those nodes
are identical to the names of the corresponding Booleans. For
example, to set the value of the user_ping
Boolean
to false, issue the command:
echo 0 > /selinux/booleans/user_ping
Unlike changes made via the change_bool
command,
changes made via the /selinux filesystem do not
immediately take effect. To commit the changes, issue the command:
echo 1 > /selinux/commit_pending_bools
All pending changes take effect immediately upon issuance of this
command.
The sestatus Command
The
Gentoo and Fedora Core 2 implementations
of SELinux include a useful new command:
sestatus. As the name of the
sestatus command suggests, the command lets you
view SELinux status information. Heres a typical
example:
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Policy version: 17
Policy booleans:
user_ping inactive
As you can see, the command reports the SELinux status and mode, the
mount point of the selinuxfs
filesystem, and the
policy version. The command also reports the value of any policy
Booleans. Policy Booleans are an SELinux feature introduced in Fedora
Core 2, and are described in the "Tuning
SELinux" section of this chapter.
The sestatus command can be issued with a
-v option, which instructs the command to issue
more verbose output that includes information concerning process and
file contexts. An example follows:
# sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Policy version: 17
Policy booleans:
user_ping inactive
Process contexts:
Current context: root:sysadm_r:sysadm_t
Init context: system_u:system_r:init_t
/sbin/mingetty system_u:system_r:getty_t
/usr/sbin/sshd root:system_r:sshd_t
File contexts:
Controlling term: root:object_r:sysadm_devpts_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:login_exec_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/sbin/init system_u:object_r:init_exec_t
/sbin/mingetty system_u:object_r:getty_exec_t
/usr/sbin/sshd system_u:object_r:sshd_exec_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:shlib_t
/lib/ld-linux.so.2
system_u:object_r:lib_t -> system_u:object_r:ld_so_t
