Linux/SELinux/01 Grundlagen

Working with SELinux

The following sections give a brief overview of the main SELinux packages in Red Hat Enterprise Linux; installing and updating packages; which log files are used; the main SELinux configuration file; enabling and disabling SELinux; SELinux modes; configuring Booleans; temporarily and persistently changing file and directory labels; overriding file system labels with the mount command; mounting NFS volumes; and how to preserve SELinux contexts when copying and archiving files and directories.

4.1. SELinux Packages

In Red Hat Enterprise Linux full installation, the SELinux packages are installed by default unless they are manually excluded during installation. If performing a minimal installation in text mode, the policycoreutils-python and the policycoreutils-gui package are not installed by default. Also, by default, SELinux runs in enforcing mode and the SELinux targeted policy is used. The following SELinux packages are installed on your system by default: * policycoreutils provides utilities such as restorecon, secon, setfiles, semodule, load_policy, and setsebool, for operating and managing SELinux.

• selinux-policy provides a basic directory structure, the selinux-policy.conf file, and RPM macros.
• selinux-policy-targeted provides the SELinux targeted policy.
• libselinux – provides an API for SELinux applications.
• libselinux-utils provides the avcstat, getenforce, getsebool, matchpathcon, selinuxconlist, selinuxdefcon, selinuxenabled, and setenforce utilities.
• libselinux-python provides Python bindings for developing SELinux applications.

The following packages are not installed by default but can be optionally installed by running the [[yum install <package-name>]] command: * selinux-policy-devel provides utilities for creating a custom SELinux policy and policy modules.

• selinux-policy-doc provides manual pages that describe how to configure SELinux altogether with various services.
• selinux-policy-mls provides the MLS (Multi-Level Security) SELinux policy.
• setroubleshoot-server translates denial messages, produced when access is denied by SELinux, into detailed descriptions that can be viewed with the sealert utility, also provided in this package.
• setools-console provides the Tresys Technology SETools distribution, a number of utilities and libraries for analyzing and querying policy, audit log monitoring and reporting, and file context management. The setools package is a meta-package for SETools. The setools-gui package provides the apol and seaudit utilities. The setools-console package provides the sechecker, sediff, seinfo, sesearch, and findcon command-line utilities. Note that setools and setools-gui packages are available only when the Red Hat Network Optional channel is enabled. For further information, see Scope of Coverage Details.
• mcstrans translates levels, such as s0-s0:c0.c1023, to a form that is easier to read, such as SystemLow-SystemHigh.
• policycoreutils-python provides utilities such as semanage, audit2allow, audit2why, and chcat, for operating and managing SELinux.
• policycoreutils-gui provides system-config-selinux, a graphical utility for managing SELinux.

4.2. Which Log File is Used

In Red Hat Enterprise Linux, the dbus and audit packages are installed by default, unless they are removed from the default package selection. The setroubleshoot-server must be installed using Yum (use the yum install setroubleshoot-server command).

If the auditd daemon is running, an SELinux denial message, such as the following, is written to /var/log/audit/audit.log by default:

type=AVC msg=audit(1223024155.684:49): avc: denied { getattr } for pid=2000 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=399185 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file

In addition, a message similar to the one below is written to the /var/log/message file:

May 7 18:55:56 localhost setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l de7e30d6-5488-466d-a606-92c9f40d316d

In Red Hat Enterprise Linux 7, setroubleshootd no longer constantly runs as a service. However, it is still used to analyze the AVC messages. Two new programs act as a method to start setroubleshoot when needed: * The sedispatch utility runs as a part of the audit subsystem. When an AVC denial message is returned, sedispatch sends a message using dbus. These messages go straight to setroubleshootd if it is already running. If it is not running, sedispatch starts it automatically.

• The seapplet utility runs in the system toolbar, waiting for dbus messages in setroubleshootd. It launches the notification bubble, allowing the user to review AVC messages.

Procedure 4.1. Starting Daemons Automatically# To configure the auditd and rsyslog daemons to automatically start at boot, enter the following commands as the root user:


~]# systemctl enable auditd.service
~]# systemctl enable rsyslog.service

1. To ensure that the daemons are enabled, type the following commands at the shell prompt:
   ~]$ systemctl is-enabled auditd
   enabled
   ~]$ systemctl is-enabled rsyslog
   enabled
   Alternatively, use the systemctl status ''service-name''.service command and search for the keyword enabled in the command output, for example:
   ~]$ systemctl status auditd.service | grep enabled
   auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled)

To learn more on how the systemd daemon manages system services, see the Managing System Services chapter in the System Administrator's Guide.

4.3. Main Configuration File

The /etc/selinux/config file is the main SELinux configuration file. It controls whether SELinux is enabled or disabled and which SELinux mode and SELinux policy is used:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#  enforcing - SELinux security policy is enforced.
#  permissive - SELinux prints warnings instead of enforcing.
#  disabled - No SELinux policy is loaded.

SELINUX=enforcing

# SELINUXTYPE= can take one of these two values:
#  targeted - Targeted processes are protected,
#  mls - Multi Level Security protection.

SELINUXTYPE=targeted

SELINUX=

The SELINUX option sets whether SELinux is disabled or enabled and in which mode - enforcing or permissive - it is running:

* When using SELINUX=enforcing, SELinux policy is enforced, and SELinux denies access based on SELinux policy rules. Denial messages are logged.

• When using SELINUX=permissive, SELinux policy is not enforced. SELinux does not deny access, but denials are logged for actions that would have been denied if running SELinux in enforcing mode.
• When using SELINUX=disabled, SELinux is disabled, the SELinux module is not registered with the Linux kernel, and only DAC rules are used.

SELINUXTYPE=

The SELINUXTYPE option sets the SELinux policy to use. Targeted policy is the default policy. Only change this option if you want to use the MLS policy. For information on how to enable the MLS policy, see Section 4.13.2, “Enabling MLS in SELinux”.

4.4. Permanent Changes in SELinux States and Modes

As discussed in Section 1.4, “SELinux States and Modes”, SELinux can be enabled or disabled. When enabled, SELinux has two modes: enforcing and permissive.

Use the getenforce or sestatus commands to check in which mode SELinux is running. The getenforce command returns Enforcing, Permissive, or Disabled.

The sestatus command returns the SELinux status and the SELinux policy being used:

~]$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 30

Note

When systems run SELinux in permissive mode, users are able to label files incorrectly. Files created while SELinux is disabled are not labeled at all. This behavior causes problems when changing to enforcing mode because files are labeled incorrectly or are not labeled at all. To prevent incorrectly labeled and unlabeled files from causing problems, file systems are automatically relabeled when changing from the disabled state to permissive or enforcing mode.

4.4.1. Enabling SELinux

When enabled, SELinux can run in one of two modes: enforcing or permissive. The following sections show how to permanently change into these modes.

While enabling SELinux on systems that previously had it disabled, to avoid problems, such as systems unable to boot or process failures, Red Hat recommends to follow this procedure: # Enable SELinux in permissive mode. For more information, see Section 4.4.1.1, “Permissive Mode”.

1. Reboot your system.
2. Check for SELinux denial messages. For more information, see Section 11.3.5, “Searching For and Viewing Denials”.
3. If there are no denials, switch to enforcing mode. For more information, see Section 4.4.1.2, “Enforcing Mode”.

To run custom applications with SELinux in enforcing mode, choose one of the following scenarios: * Run your application in the unconfined_service_t domain. See Section 3.2, “Unconfined Processes” for more information.

• Write a new policy for your application. See the Writing Custom SELinux Policy Knowledgebase article for more information.

4.4.1.1. Permissive Mode

When SELinux is running in permissive mode, SELinux policy is not enforced. The system remains operational and SELinux does not deny any operations but only logs AVC messages, which can be then used for troubleshooting, debugging, and SELinux policy improvements. Each AVC is logged only once in this case.

To permanently change mode to permissive, follow the procedure below:

Procedure 4.2. Changing to Permissive Mode# Edit the /etc/selinux/config file as follows:


# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

1. Reboot the system:
   

~]# reboot

4.4.1.2. Enforcing Mode

When SELinux is running in enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. In Red Hat Enterprise Linux, enforcing mode is enabled by default when the system was initially installed with SELinux.

If SELinux was disabled, follow the procedure below to change mode to enforcing again:

Procedure 4.3. Changing to Enforcing Mode

This procedure assumes that the selinux-policy-targeted, selinux-policy, libselinux, libselinux-python, libselinux-utils, policycoreutils, and policycoreutils-python packages are installed. To verify that the packages are installed, use the following command:

rpm -q package_name

1. Edit the /etc/selinux/config file as follows:
   

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

1. Reboot the system:
   

~]# reboot


On the next boot, SELinux relabels all the files and directories within the system and adds SELinux context for files and directories that were created when SELinux was disabled.

Note

After changing to enforcing mode, SELinux may deny some actions because of incorrect or missing SELinux policy rules. To view what actions SELinux denies, enter the following command as root:

~]# ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today

Alternatively, with the setroubleshoot-server package installed, enter the following command as root:

~]# grep "SELinux is preventing" /var/log/messages

If SELinux denies some actions, see Chapter 11, Troubleshooting for information about troubleshooting.

Temporary changes in modes are covered in Section 1.4, “SELinux States and Modes”.

4.4.2. Disabling SELinux

When SELinux is disabled, SELinux policy is not loaded at all; it is not enforced and AVC messages are not logged. Therefore, all benefits of running SELinux listed in Section 1.1, “Benefits of running SELinux” are lost.

Important

Red Hat strongly recommends to use permissive mode instead of permanently disabling SELinux. See Section 4.4.1.1, “Permissive Mode” for more information about permissive mode.

To permanently disable SELinux, follow the procedure below:

Procedure 4.4. Disabling SELinux# Configure SELINUX=disabled in the /etc/selinux/config file:


# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

1. Reboot your system. After reboot, confirm that the getenforce command returns Disabled:
   

~]$ getenforce
Disabled

4.5. Changing SELinux Modes at Boot Time

On boot, you can set several kernel parameters to change the way SELinux runs:

enforcing=0

Setting this parameter causes the system to start in permissive mode, which is useful when troubleshooting issues. Using permissive mode might be the only option to detect a problem if your file system is too corrupted. Moreover, in permissive mode, the system continues to create the labels correctly. The AVC messages that are created in this mode can be different than in enforcing mode.

In permissive mode, only the first denial from a series of the same denials is reported. However, in enforcing mode, you might get a denial related to reading a directory, and an application stops. In permissive mode, you get the same AVC message, but the application continues reading files in the directory and you get an AVC for each denial in addition.

selinux=0

This parameter causes the kernel to not load any part of the SELinux infrastructure. The init scripts notice that the system booted with the selinux=0 parameter and touch the /.autorelabel file. This causes the system to automatically relabel the next time you boot with SELinux enabled.

Important

Red Hat does not recommend using the selinux=0 parameter. To debug your system, prefer using permissive mode.

autorelabel=1

This parameter forces the system to relabel similarly to the following commands:

~]# touch /.autorelabel ~]# reboot

If the system labeling contains a large amount of errors, you might need to boot in permissive mode in order that the autorelabel succeeds.

For additional SELinux-related kernel boot parameters, such as checkreqprot, see the [[/usr/share/doc/kernel-doc-<KERNEL_VER>/Documentation/kernel-parameters.txt]] file. This documentation is installed with the kernel-doc package. Replace the <KERNEL_VER> string with the version number of the installed kernel, for example:

~]# yum install kernel-doc ~]$ less /usr/share/doc/kernel-doc-3.10.0/Documentation/kernel-parameters.txt

4.6. Booleans

Booleans allow parts of SELinux policy to be changed at runtime, without any knowledge of SELinux policy writing. This allows changes, such as allowing services access to NFS volumes, without reloading or recompiling SELinux policy.

4.6.1. Listing Booleans

For a list of Booleans, an explanation of what each one is, and whether they are on or off, run the semanage boolean -l command as the Linux root user. The following example does not list all Booleans and the output is shortened for brevity:

~]# semanage boolean -l SELinux boolean State Default Description

smartmon_3ware (off , off) Determine whether smartmon can... mpd_enable_homedirs (off , off) Determine whether mpd can traverse...

Note

To have more detailed descriptions, install the selinux-policy-devel package.

The SELinux boolean column lists Boolean names. The Description column lists whether the Booleans are on or off, and what they do.

The getsebool -a command lists Booleans, whether they are on or off, but does not give a description of each one. The following example does not list all Booleans:

~]$ getsebool -a cvs_read_shadow --> off daemons_dump_core --> on

Run the getsebool ''boolean-name'' command to only list the status of the boolean-name Boolean:

~]$ getsebool cvs_read_shadow cvs_read_shadow --> off

Use a space-separated list to list multiple Booleans:

~]$ getsebool cvs_read_shadow daemons_dump_core cvs_read_shadow --> off daemons_dump_core --> on

4.6.2. Configuring Booleans

Run the setsebool utility in the setsebool ''boolean_name'' on/off form to enable or disable Booleans.

The following example demonstrates configuring the httpd_can_network_connect_db Boolean:

Procedure 4.5. Configuring Booleans# By default, the httpd_can_network_connect_db Boolean is off, preventing Apache HTTP Server scripts and modules from connecting to database servers:


~]$ getsebool httpd_can_network_connect_db
httpd_can_network_connect_db --> off

1. To temporarily enable Apache HTTP Server scripts and modules to connect to database servers, enter the following command as root:
   

~]# setsebool httpd_can_network_connect_db on

1. Use the getsebool utility to verify the Boolean has been enabled:
   

~]$ getsebool httpd_can_network_connect_db
httpd_can_network_connect_db --> on


This allows Apache HTTP Server scripts and modules to connect to database servers.

1. This change is not persistent across reboots. To make changes persistent across reboots, run the setsebool -P ''boolean-name'' on command as root:[3]
   

~]# setsebool -P httpd_can_network_connect_db on

4.6.3. Shell Auto-Completion

It is possible to use shell auto-completion with the getsebool, setsebool, and semanage utilities. Use the auto-completion with getsebool and setsebool to complete both command-line parameters and Booleans. To list only the command-line parameters, add the hyphen character ("-") after the command name and hit the Tab key:

~]# setsebool -[Tab] -P

To complete a Boolean, start writing the Boolean name and then hit Tab:

~]$ getsebool samba_[Tab] samba_create_home_dirs samba_export_all_ro samba_run_unconfined samba_domain_controller samba_export_all_rw samba_share_fusefs samba_enable_home_dirs samba_portmapper samba_share_nfs

~]# setsebool -P virt_use_[Tab] virt_use_comm virt_use_nfs virt_use_sanlock virt_use_execmem virt_use_rawip virt_use_usb virt_use_fusefs virt_use_samba virt_use_xserver

The semanage utility is used with several command-line arguments that are completed one by one. The first argument of a semanage command is an option, which specifies what part of SELinux policy is managed:

~]# semanage [Tab] boolean export import login node port dontaudit fcontext interface module permissive user

Then, one or more command-line parameters follow:

~]# semanage fcontext -[Tab] -a -D --equal --help -m -o --add --delete -f -l --modify -S -C --deleteall --ftype --list -n -t -d -e -h --locallist --noheading --type

Finally, complete the name of a particular SELinux entry, such as a Boolean, SELinux user, domain, or another. Start typing the entry and hit Tab:

~]# semanage fcontext -a -t samba<tab> samba_etc_t samba_secrets_t sambagui_exec_t samba_share_t samba_initrc_exec_t samba_unconfined_script_exec_t samba_log_t samba_unit_file_t samba_net_exec_t

Command-line parameters can be chained in a command:

~]# semanage port -a -t http_port_t -p tcp 81

4.7. SELinux Contexts – Labeling Files

On systems running SELinux, all processes and files are labeled in a way that represents security-relevant information. This information is called the SELinux context. For files, this is viewed using the ls -Z command:

~]$ ls -Z file1 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. On DAC systems, access is controlled based on Linux user and group IDs. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.

Note

By default, newly-created files and directories inherit the SELinux type of their parent directories. For example, when creating a new file in the /etc directory that is labeled with the etc_t type, the new file inherits the same type:

~]$ ls -dZ - /etc drwxr-xr-x. root root system_u:object_r:etc_t:s0 /etc

~]# touch /etc/file1

~]# ls -lZ /etc/file1 -rw-r--r--. root root unconfined_u:object_r:etc_t:s0 /etc/file1

SELinux provides multiple commands for managing the file system labeling, such as chcon, semanage fcontext, restorecon, and matchpathcon.

4.7.1. Temporary Changes: chcon

The chcon command changes the SELinux context for files. However, changes made with the chcon command are not persistent across file-system relabels, or the execution of the restorecon command. SELinux policy controls whether users are able to modify the SELinux context for any given file. When using chcon, users provide all or part of the SELinux context to change. An incorrect file type is a common cause of SELinux denying access.

Quick Reference

• Run the chcon -t ''type'' ''file-name'' command to change the file type, where type is an SELinux type, such as httpd_sys_content_t, and file-name is a file or directory name:
  

~]$ chcon -t httpd_sys_content_t file-name

• Run the chcon -R -t ''type'' ''directory-name'' command to change the type of the directory and its contents, where type is an SELinux type, such as httpd_sys_content_t, and directory-name is a directory name:
  

~]$ chcon -R -t httpd_sys_content_t directory-name

Procedure 4.6. Changing a File's or Directory's Type

The following procedure demonstrates changing the type, and no other attributes of the SELinux context. The example in this section works the same for directories, for example, if file1 was a directory. # Change into your home directory.

1. Create a new file and view its SELinux context:
   

~]$ touch file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1


In this example, the SELinux context for file1 includes the SELinux unconfined_u user, object_r role, user_home_t type, and the s0 level. For a description of each part of the SELinux context, see Chapter 2, SELinux Contexts.

1. Enter the following command to change the type to samba_share_t. The -t option only changes the type. Then view the change:
   

~]$ chcon -t samba_share_t file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:samba_share_t:s0 file1

1. Use the following command to restore the SELinux context for the file1 file. Use the -v option to view what changes:
   

~]$ restorecon -v file1
restorecon reset file1 context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:user_home_t:s0




In this example, the previous type, samba_share_t, is restored to the correct, user_home_t type. When using targeted policy (the default SELinux policy in Red Hat Enterprise Linux), the restorecon command reads the files in the /etc/selinux/targeted/contexts/files/ directory, to see which SELinux context files should have.

Procedure 4.7. Changing a Directory and its Contents Types

The following example demonstrates creating a new directory, and changing the directory's file type along with its contents to a type used by the Apache HTTP Server. The configuration in this example is used if you want Apache HTTP Server to use a different document root (instead of /var/www/html/): # As the root user, create a new web/ directory and then 3 empty files (file1, file2, and file3) within this directory. The web/ directory and files in it are labeled with the default_t type:


~]# mkdir /web





~]# touch /web/file{1,2,3}





~]# ls -dZ /web
drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web





~]# ls -lZ /web
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3

1. As root, enter the following command to change the type of the web/ directory (and its contents) to httpd_sys_content_t:
   

~]# chcon -R -t httpd_sys_content_t /web/





~]# ls -dZ /web/
drwxr-xr-x root root unconfined_u:object_r:httpd_sys_content_t:s0 /web/





~]# ls -lZ /web/
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file3

1. To restore the default SELinux contexts, use the restorecon utility as root:
   

~]# restorecon -R -v /web/
restorecon reset /web context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0
restorecon reset /web/file2 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0
restorecon reset /web/file3 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0
restorecon reset /web/file1 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0

See the chcon(1) manual page for further information about chcon.

Note

Type Enforcement is the main permission control used in SELinux targeted policy. For the most part, SELinux users and roles can be ignored.

4.7.2. Persistent Changes: semanage fcontext

The semanage fcontext command is used to change the SELinux context of files. To show contexts to newly created files and directories, enter the following command as root:

~]# semanage fcontext -C -l

Changes made by semanage fcontext are used by the following utilities. The setfiles utility is used when a file system is relabeled and the restorecon utility restores the default SELinux contexts. This means that changes made by semanage fcontext are persistent, even if the file system is relabeled. SELinux policy controls whether users are able to modify the SELinux context for any given file.

Quick Reference

To make SELinux context changes that survive a file system relabel: # Enter the following command, remembering to use the full path to the file or directory:


~]# semanage fcontext -a options file-name|directory-name

1. Use the restorecon utility to apply the context changes:
   

~]# restorecon -v file-name|directory-name

Use of regular expressions with semanage fcontext

For the semanage fcontext command to work correctly, you can use either a fully qualified path or Perl-compatible regular expressions (). The only PCRE flag in use is PCRE2_DOTALL, which causes the [[.]] wildcard to match anything, including a new line. Strings representing paths are processed as bytes, meaning that non-ASCII characters are not matched by a single wildcard.

Note that file-context definitions specified using semanage fcontext are evaluated in reverse order to how they were defined: the latest entry is evaluated first regardless of the stem length. Local file context modifications stored in file_contexts.local have a higher priority than those specified in policy modules. This means that whenever a match for a given file path is found in file_contexts.local, no other file-context definitions are considered.

Important

File-context definitions specified using the semanage fcontext command effectively override all other file-context definitions. All regular expressions should therefore be as specific as possible to avoid unintentionally impacting other parts of the file system.

For more information on a type of regular expression used in file-context definitions and flags in effect, see the semanage-fcontext(8) man page.

Procedure 4.8. Changing a File's or Directory 's Type

The following example demonstrates changing a file's type, and no other attributes of the SELinux context. This example works the same for directories, for instance if file1 was a directory. # As the root user, create a new file in the /etc directory. By default, newly-created files in /etc are labeled with the etc_t type:


~]# touch /etc/file1





~]$ ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1


To list information about a directory, use the following command:


~]$ ls -dZ directory_name

1. As root, enter the following command to change the file1 type to samba_share_t. The -a option adds a new record, and the -t option defines a type (samba_share_t). Note that running this command does not directly change the type; file1 is still labeled with the etc_t type:
   

~]# semanage fcontext -a -t samba_share_t /etc/file1





~]# ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1





~]$ semanage fcontext -C -l
/etc/file1 unconfined_u:object_r:samba_share_t:s0

1. As root, use the restorecon utility to change the type. Because semanage added an entry to file_contexts.local for /etc/file1, restorecon changes the type to samba_share_t:
   

~]# restorecon -v /etc/file1
restorecon reset /etc/file1 context unconfined_u:object_r:etc_t:s0->system_u:object_r:samba_share_t:s0

Procedure 4.9. Changing a Directory and its Contents Types

The following example demonstrates creating a new directory, and changing the directory's file type along with its contents to a type used by Apache HTTP Server. The configuration in this example is used if you want Apache HTTP Server to use a different document root instead of /var/www/html/: # As the root user, create a new web/ directory and then 3 empty files (file1, file2, and file3) within this directory. The web/ directory and files in it are labeled with the default_t type:


~]# mkdir /web





~]# touch /web/file{1,2,3}





~]# ls -dZ /web
drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web





~]# ls -lZ /web
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3

1. As root, enter the following command to change the type of the web/ directory and the files in it, to httpd_sys_content_t. The -a option adds a new record, and the -t option defines a type (httpd_sys_content_t). The "/web(/.*)?" regular expression causes semanage to apply changes to web/, as well as the files in it. Note that running this command does not directly change the type; web/ and files in it are still labeled with the default_t type:
   

~]# semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"





~]$ ls -dZ /web
drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web





~]$ ls -lZ /web
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3


The semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?" command adds the following entry to /etc/selinux/targeted/contexts/files/file_contexts.local:


/web(/.*)? system_u:object_r:httpd_sys_content_t:s0

1. As root, use the restorecon utility to change the type of web/, as well as all files in it. The -R is for recursive, which means all files and directories under web/ are labeled with the httpd_sys_content_t type. Since semanage added an entry to file.contexts.local for /web(/.*)?, restorecon changes the types to httpd_sys_content_t:
   

~]# restorecon -R -v /web
restorecon reset /web context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /web/file2 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /web/file3 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /web/file1 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0




Note that by default, newly-created files and directories inherit the SELinux type of their parent directories.

Procedure 4.10. Deleting an added Context

The following example demonstrates adding and removing an SELinux context. If the context is part of a regular expression, for example, /web(/.*)?, use quotation marks around the regular expression:

~]# semanage fcontext -d "/web(/.*)?"

1. To remove the context, as root, enter the following command, where file-name|directory-name is the first part in file_contexts.local:
   

~]# semanage fcontext -d file-name|directory-name


The following is an example of a context in file_contexts.local:


/test system_u:object_r:httpd_sys_content_t:s0


With the first part being test. To prevent the test/ directory from being labeled with the httpd_sys_content_t after running restorecon, or after a file system relabel, enter the following command as root to delete the context from file_contexts.local:


~]# semanage fcontext -d /test

1. As root, use the restorecon utility to restore the default SELinux context.

For further information about semanage, see the semanage(8) and semanage-fcontext(8) manual pages.

Important

When changing the SELinux context with semanage fcontext -a, use the full path to the file or directory to avoid files being mislabeled after a file system relabel, or after the restorecon command is run.

4.7.3. How File Context is Determined

Determining file context is based on file-context definitions, which are specified in the system security policy (the .fc files). Based on the system policy, semanage generates file_contexts.homedirs and file_contexts files.

System administrators can customize file-context definitions using the semanage fcontext command. Such customizations are stored in the file_contexts.local file.

When a labeling utility, such as matchpathcon or restorecon, is determining the proper label for a given path, it searches for local changes first (file_contexts.local). If the utility does not find a matching pattern, it searches the file_contexts.homedirs file and finally the file_contexts file. However, whenever a match for a given file path is found, the search ends, the utility does look for any additional file-context definitions. This means that home directory-related file contexts have higher priority than the rest, and local customizations override the system policy.

File-context definitions specified by system policy (contents of file_contexts.homedirs and file_contexts files) are sorted by the length of the stem (prefix of the path before any wildcard) before evaluation. This means that the most specific path is chosen. However, file-context definitions specified using semanage fcontext are evaluated in reverse order to how they were defined: the latest entry is evaluated first regardless of the stem length.

For more information on: * changing the context of a file by using chcon, see Section 4.7.1, “Temporary Changes: chcon”.

• changing and adding a file-context definition by using semanage fcontext, see Section 4.7.2, “Persistent Changes: semanage fcontext”.
• changing and adding a file-context definition through a system-policy operation, see Section 4.10, “Maintaining SELinux Labels” or Section 4.12, “Prioritizing and Disabling SELinux Policy Modules”.

4.8. The file_t and default_t Types

When using a file system that supports extended attributes (EA), the file_t type is the default type of a file that has not yet been assigned EA value. This type is only used for this purpose and does not exist on correctly-labeled file systems, because all files on a system running SELinux should have a proper SELinux context, and the file_t type is never used in file-context configuration[4].

The default_t type is used on files that do not match any pattern in file-context configuration, so that such files can be distinguished from files that do not have a context on disk, and generally are kept inaccessible to confined domains. For example, if you create a new top-level directory, such as mydirectory/, this directory may be labeled with the default_t type. If services need access to this directory, you need to update the file-contexts configuration for this location. See Section 4.7.2, “Persistent Changes: semanage fcontext” for details on adding a context to the file-context configuration.

4.9. Mounting File Systems

By default, when a file system that supports extended attributes is mounted, the security context for each file is obtained from the security.selinux extended attribute of the file. Files in file systems that do not support extended attributes are assigned a single, default security context from the policy configuration, based on file system type.

Use the mount -o context command to override existing extended attributes, or to specify a different, default context for file systems that do not support extended attributes. This is useful if you do not trust a file system to supply the correct attributes, for example, removable media used in multiple systems. The mount -o context command can also be used to support labeling for file systems that do not support extended attributes, such as File Allocation Table (FAT) or NFS volumes. The context specified with the context option is not written to disk: the original contexts are preserved, and are seen when mounting without context if the file system had extended attributes in the first place.

For further information about file system labeling, see James Morris's "Filesystem Labeling in SELinux" article: http://www.linuxjournal.com/article/7426.

4.9.1. Context Mounts

To mount a file system with the specified context, overriding existing contexts if they exist, or to specify a different, default context for a file system that does not support extended attributes, as the root user, use the mount -o context=''SELinux_user:role:type:level'' command when mounting the required file system. Context changes are not written to disk. By default, NFS mounts on the client side are labeled with a default context defined by policy for NFS volumes. In common policies, this default context uses the nfs_t type. Without additional mount options, this may prevent sharing NFS volumes using other services, such as the Apache HTTP Server. The following example mounts an NFS volume so that it can be shared using the Apache HTTP Server:

~]# mount server:/export /local/mount/point -o \ context="system_u:object_r:httpd_sys_content_t:s0"

Newly-created files and directories on this file system appear to have the SELinux context specified with -o context. However, since these changes are not written to disk, the context specified with this option does not persist between mounts. Therefore, this option must be used with the same context specified during every mount to retain the required context. For information about making context mount persistent, see Section 4.9.5, “Making Context Mounts Persistent”.

Type Enforcement is the main permission control used in SELinux targeted policy. For the most part, SELinux users and roles can be ignored, so, when overriding the SELinux context with -o context, use the SELinux system_u user and object_r role, and concentrate on the type. If you are not using the MLS policy or multi-category security, use the s0 level.

Note

When a file system is mounted with a context option, context changes by users and processes are prohibited. For example, running the chcon command on a file system mounted with a context option results in a Operation not supported error.

4.9.2. Changing the Default Context

As mentioned in Section 4.8, “The file_t and default_t Types”, on file systems that support extended attributes, when a file that lacks an SELinux context on disk is accessed, it is treated as if it had a default context as defined by SELinux policy. In common policies, this default context uses the file_t type. If it is desirable to use a different default context, mount the file system with the defcontext option.

The following example mounts a newly-created file system on /dev/sda2 to the newly-created test/ directory. It assumes that there are no rules in /etc/selinux/targeted/contexts/files/ that define a context for the test/ directory:

~]# mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"

In this example: * the defcontext option defines that system_u:object_r:samba_share_t:s0 is "the default security context for unlabeled files"[5].

• when mounted, the root directory (test/) of the file system is treated as if it is labeled with the context specified by defcontext (this label is not stored on disk). This affects the labeling for files created under test/: new files inherit the samba_share_t type, and these labels are stored on disk.
• files created under test/ while the file system was mounted with a defcontext option retain their labels.

4.9.3. Mounting an NFS Volume

By default, NFS mounts on the client side are labeled with a default context defined by policy for NFS volumes. In common policies, this default context uses the nfs_t type. Depending on policy configuration, services, such as Apache HTTP Server and MariaDB, may not be able to read files labeled with the nfs_t type. This may prevent file systems labeled with this type from being mounted and then read or exported by other services.

If you would like to mount an NFS volume and read or export that file system with another service, use the context option when mounting to override the nfs_t type. Use the following context option to mount NFS volumes so that they can be shared using the Apache HTTP Server:

~]# mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0"

Since these changes are not written to disk, the context specified with this option does not persist between mounts. Therefore, this option must be used with the same context specified during every mount to retain the required context. For information about making context mount persistent, see Section 4.9.5, “Making Context Mounts Persistent”.

As an alternative to mounting file systems with context options, Booleans can be enabled to allow services access to file systems labeled with the nfs_t type. See Part II, “Managing Confined Services” for instructions on configuring Booleans to allow services access to the nfs_t type.

4.9.4. Multiple NFS Mounts

When mounting multiple mounts from the same NFS export, attempting to override the SELinux context of each mount with a different context, results in subsequent mount commands failing. In the following example, the NFS server has a single export, export/, which has two subdirectories, web/ and database/. The following commands attempt two mounts from a single NFS export, and try to override the context for each one:

~]# mount server:/export/web /local/web -o context="system_u:object_r:httpd_sys_content_t:s0"

~]# mount server:/export/database /local/database -o context="system_u:object_r:mysqld_db_t:s0"

The second mount command fails, and the following is logged to /var/log/messages:

kernel: SELinux: mount invalid. Same superblock, different security settings for (dev 0:15, type nfs)

To mount multiple mounts from a single NFS export, with each mount having a different context, use the -o nosharecache,context options. The following example mounts multiple mounts from a single NFS export, with a different context for each mount (allowing a single service access to each one):

~]# mount server:/export/web /local/web -o nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"

~]# mount server:/export/database /local/database -o \ nosharecache,context="system_u:object_r:mysqld_db_t:s0"

In this example, server:/export/web is mounted locally to the /local/web/ directory, with all files being labeled with the httpd_sys_content_t type, allowing Apache HTTP Server access. server:/export/database is mounted locally to /local/database/, with all files being labeled with the mysqld_db_t type, allowing MariaDB access. These type changes are not written to disk.

Important

The nosharecache options allows you to mount the same subdirectory of an export multiple times with different contexts, for example, mounting /export/web/ multiple times. Do not mount the same subdirectory from an export multiple times with different contexts, as this creates an overlapping mount, where files are accessible under two different contexts.

4.9.5. Making Context Mounts Persistent

To make context mounts persistent across remounting and reboots, add entries for the file systems in the /etc/fstab file or an automounter map, and use the required context as a mount option. The following example adds an entry to /etc/fstab for an NFS context mount:

server:/export /local/mount/ nfs context="system_u:object_r:httpd_sys_content_t:s0" 0 0

4.10. Maintaining SELinux Labels

These sections describe what happens to SELinux contexts when copying, moving, and archiving files and directories. Also, it explains how to preserve contexts when copying and archiving.

4.10.1. Copying Files and Directories

When a file or directory is copied, a new file or directory is created if it does not exist. That new file or directory's context is based on default-labeling rules, not the original file or directory's context unless options were used to preserve the original context. For example, files created in user home directories are labeled with the user_home_t type:

~]$ touch file1

~]$ ls -Z file1 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

If such a file is copied to another directory, such as /etc, the new file is created in accordance to default-labeling rules for /etc. Copying a file without additional options may not preserve the original context:

~]$ ls -Z file1 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

~]# cp file1 /etc/

~]$ ls -Z /etc/file1 -rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1

When file1 is copied to /etc, if /etc/file1 does not exist, /etc/file1 is created as a new file. As shown in the example above, /etc/file1 is labeled with the etc_t type, in accordance to default-labeling rules.

When a file is copied over an existing file, the existing file's context is preserved, unless the user specified cp options to preserve the context of the original file, such as --preserve=context. SELinux policy may prevent contexts from being preserved during copies.

Procedure 4.11. Copying Without Preserving SELinux Contexts

This procedure shows that when copying a file with the cp command, if no options are given, the type is inherited from the targeted, parent directory. # Create a file in a user's home directory. The file is labeled with the user_home_t type:


~]$ touch file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

1. The /var/www/html/ directory is labeled with the httpd_sys_content_t type, as shown with the following command:
   

~]$ ls -dZ /var/www/html/
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/

1. When file1 is copied to /var/www/html/, it inherits the httpd_sys_content_t type:
   

~]# cp file1 /var/www/html/





~]$ ls -Z /var/www/html/file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/file1

Procedure 4.12. Preserving SELinux Contexts When Copying

This procedure shows how to use the --preserve=context option to preserve contexts when copying. # Create a file in a user's home directory. The file is labeled with the user_home_t type:


~]$ touch file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

1. The /var/www/html/ directory is labeled with the httpd_sys_content_t type, as shown with the following command:
   

~]$ ls -dZ /var/www/html/
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/

1. Using the --preserve=context option preserves SELinux contexts during copy operations. As shown below, the user_home_t type of file1 was preserved when the file was copied to /var/www/html/:
   

~]# cp --preserve=context file1 /var/www/html/





~]$ ls -Z /var/www/html/file1
-rw-r--r-- root root unconfined_u:object_r:user_home_t:s0 /var/www/html/file1

Procedure 4.13. Copying and Changing the Context

This procedure show how to use the --context option to change the destination copy's context. The following example is performed in the user's home directory: # Create a file in a user's home directory. The file is labeled with the user_home_t type:


~]$ touch file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

1. Use the --context option to define the SELinux context:
   

~]$ cp --context=system_u:object_r:samba_share_t:s0 file1 file2

1. Without --context, file2 would be labeled with the unconfined_u:object_r:user_home_t context:
   

~]$ ls -Z file1 file2
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
-rw-rw-r-- user1 group1 system_u:object_r:samba_share_t:s0 file2

Procedure 4.14. Copying a File Over an Existing File

This procedure shows that when a file is copied over an existing file, the existing file's context is preserved unless an option is used to preserve contexts. # As root, create a new file, file1 in the /etc directory. As shown below, the file is labeled with the etc_t type:


~]# touch /etc/file1





~]$ ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1

1. Create another file, file2, in the /tmp directory. As shown below, the file is labeled with the user_tmp_t type:
   

~]$ touch /tmp/file2





~$ ls -Z /tmp/file2
-rw-r--r-- root root unconfined_u:object_r:user_tmp_t:s0 /tmp/file2

1. Overwrite file1 with file2:
   

~]# cp /tmp/file2 /etc/file1

1. After copying, the following command shows file1 labeled with the etc_t type, not the user_tmp_t type from /tmp/file2 that replaced /etc/file1:
   

~]$ ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1

Important

Copy files and directories, rather than moving them. This helps ensure they are labeled with the correct SELinux contexts. Incorrect SELinux contexts can prevent processes from accessing such files and directories.

4.10.2. Moving Files and Directories

Files and directories keep their current SELinux context when they are moved. In many cases, this is incorrect for the location they are being moved to. The following example demonstrates moving a file from a user's home directory to the /var/www/html/ directory, which is used by the Apache HTTP Server. Since the file is moved, it does not inherit the correct SELinux context:

Procedure 4.15. Moving Files and Directories# Change into your home directory and create file in it. The file is labeled with the user_home_t type:


~]$ touch file1





~]$ ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

1. Enter the following command to view the SELinux context of the /var/www/html/ directory:
   

~]$ ls -dZ /var/www/html/
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/


By default, /var/www/html/ is labeled with the httpd_sys_content_t type. Files and directories created under /var/www/html/ inherit this type, and as such, they are labeled with this type.

1. As root, move file1 to /var/www/html/. Since this file is moved, it keeps its current user_home_t type:
   

~]# mv file1 /var/www/html/





~]# ls -Z /var/www/html/file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 /var/www/html/file1

By default, the Apache HTTP Server cannot read files that are labeled with the user_home_t type. If all files comprising a web page are labeled with the user_home_t type, or another type that the Apache HTTP Server cannot read, permission is denied when attempting to access them using web browsers, such as Mozilla Firefox.

Important

Moving files and directories with the mv command may result in the incorrect SELinux context, preventing processes, such as the Apache HTTP Server and Samba, from accessing such files and directories.

4.10.3. Checking the Default SELinux Context

Use the matchpathcon utility to check if files and directories have the correct SELinux context. This utility queries the system policy and then provides the default security context associated with the file path.[6] The following example demonstrates using matchpathcon to verify that files in /var/www/html/ directory are labeled correctly:

Procedure 4.16. Checking the Default SELinux Conxtext with matchpathcon'''# As the root user, create three files (file1, file2, and file3) in the /var/www/html/ directory. These files inherit the httpd_sys_content_t type from /var/www/html/:


~]# touch /var/www/html/file{1,2,3}





~]# ls -Z /var/www/html/
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file3

1. As root, change the file1 type to samba_share_t. Note that the Apache HTTP Server cannot read files or directories labeled with the samba_share_t type.
   

~]# chcon -t samba_share_t /var/www/html/file1

1. The matchpathcon -V option compares the current SELinux context to the correct, default context in SELinux policy. Enter the following command to check all files in the /var/www/html/ directory:
   

~]$ matchpathcon -V /var/www/html/*
/var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/file2 verified.
/var/www/html/file3 verified.

The following output from the matchpathcon command explains that file1 is labeled with the samba_share_t type, but should be labeled with the httpd_sys_content_t type:

/var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

To resolve the label problem and allow the Apache HTTP Server access to file1, as root, use the restorecon utility:

~]# restorecon -v /var/www/html/file1 restorecon reset /var/www/html/file1 context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0

4.10.4. Archiving Files with tar

The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux command to create archives that retain contexts and to restore files from the archives. If a tar archive contains files without extended attributes, or if you want the extended attributes to match the system defaults, use the restorecon utility:

~]$ tar -xvf archive.tar | restorecon -f -

Note that depending on the directory, you may need to be the root user to run the restorecon.

The following example demonstrates creating a tar archive that retains SELinux contexts:

Procedure 4.17. Creating a tar Archive# Change to the /var/www/html/ directory and view its SELinux context:


~]$ cd /var/www/html/





html]$ ls -dZ /var/www/html/
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .

1. As root, create three files (file1, file2, and file3) in /var/www/html/. These files inherit the httpd_sys_content_t type from /var/www/html/:
   

html]# touch file{1,2,3}





html]$ ls -Z /var/www/html/
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file3

1. As root, enter the following command to create a tar archive named test.tar. Use the --selinux to retain the SELinux context:
   

html]# tar --selinux -cf test.tar file{1,2,3}

1. As root, create a new directory named test/, and then allow all users full access to it:
   

~]# mkdir /test





~]# chmod 777 /test/

1. Copy the test.tar file into test/:
   

~]$ cp /var/www/html/test.tar /test/

1. Change into test/ directory. Once in this directory, enter the following command to extract the tar archive. Specify the --selinux option again otherwise the SELinux context will be changed to default_t:
   

~]$ cd /test/





test]$ tar --selinux -xvf test.tar

1. View the SELinux contexts. The httpd_sys_content_t type has been retained, rather than being changed to default_t, which would have happened had the --selinux not been used:
   

test]$ ls -lZ /test/
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file3
-rw-r--r-- user1 group1 unconfined_u:object_r:default_t:s0 test.tar

1. If the test/ directory is no longer required, as root, enter the following command to remove it, as well as all files in it:
   

~]# rm -ri /test/

See the tar(1) manual page for further information about tar, such as the --xattrs option that retains all extended attributes.

4.10.5. Archiving Files with star

The star utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the star -xattr -H=exustar command to create archives that retain contexts. The star package is not installed by default. To install star, run the yum install star command as the root user.

The following example demonstrates creating a star archive that retains SELinux contexts:

Procedure 4.18. Creating a star Archive# As root, create three files (file1, file2, and file3) in the /var/www/html/. These files inherit the httpd_sys_content_t type from /var/www/html/:


~]# touch /var/www/html/file{1,2,3}





~]# ls -Z /var/www/html/
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file3

1. Change into /var/www/html/ directory. Once in this directory, as root, enter the following command to create a star archive named test.star:
   

~]$ cd /var/www/html





html]# star -xattr -H=exustar -c -f=test.star file{1,2,3}
star: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).

1. As root, create a new directory named test/, and then allow all users full access to it:
   

~]# mkdir /test





~]# chmod 777 /test/

1. Enter the following command to copy the test.star file into test/:
   

~]$ cp /var/www/html/test.star /test/

1. Change into test/. Once in this directory, enter the following command to extract the star archive:
   

~]$ cd /test/





test]$ star -x -f=test.star
star: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).

1. View the SELinux contexts. The httpd_sys_content_t type has been retained, rather than being changed to default_t, which would have happened had the -xattr -H=exustar option not been used:
   

~]$ ls -lZ /test/
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- user1 group1 unconfined_u:object_r:httpd_sys_content_t:s0 file3
-rw-r--r-- user1 group1 unconfined_u:object_r:default_t:s0 test.star

1. If the test/ directory is no longer required, as root, enter the following command to remove it, as well as all files in it:
   

~]# rm -ri /test/

1. If star is no longer required, as root, remove the package:
   

~]# yum remove star

See the star(1) manual page for further information about star.

4.11. Information Gathering Tools

The utilities listed below are command-line tools that provide well-formatted information, such as access vector cache statistics or the number of classes, types, or Booleans.

avcstat

This command provides a short output of the access vector cache statistics since boot. You can watch the statistics in real time by specifying a time interval in seconds. This provides updated statistics since the initial output. The statistics file used is /sys/fs/selinux/avc/cache_stats, and you can specify a different cache file with the -f /path/to/file option.

~]# avcstat

lookups hits misses allocs reclaims frees
47517410 47504630 12780 12780 12176 12275

seinfo

This utility is useful in describing the break-down of a policy, such as the number of classes, types, Booleans, allow rules, and others. seinfo is a command-line utility that uses a policy.conf file, a binary policy file, a modular list of policy packages, or a policy list file as input. You must have the setools-console package installed to use the seinfo utility.

The output of seinfo will vary between binary and source files. For example, the policy source file uses the [[{ }]] brackets to group multiple rule elements onto a single line. A similar effect happens with attributes, where a single attribute expands into one or many types. Because these are expanded and no longer relevant in the binary policy file, they have a return value of zero in the search results. However, the number of rules greatly increases as each formerly one line rule using brackets is now a number of individual lines.

Some items are not present in the binary policy. For example, neverallow rules are only checked during policy compile, not during runtime, and initial Security Identifiers (SIDs) are not part of the binary policy since they are required prior to the policy being loaded by the kernel during boot.

~]# seinfo

Statistics for policy file: /sys/fs/selinux/policy Policy Version & Type: v.28 (binary, mls)

Classes: 77 Permissions: 229
Sensitivities: 1 Categories: 1024
Types: 3001 Attributes: 244
Users: 9 Roles: 13
Booleans: 158 Cond. Expr.: 193
Allow: 262796 Neverallow: 0
Auditallow: 44 Dontaudit: 156710
Type_trans: 10760 Type_change: 38
Type_member: 44 Role allow: 20
Role_trans: 237 Range_trans: 2546
Constraints: 62 Validatetrans: 0
Initial SIDs: 27 Fs_use: 22
Genfscon: 82 Portcon: 373
Netifcon: 0 Nodecon: 0
Permissives: 22 Polcap: 2

The seinfo utility can also list the number of types with the domain attribute, giving an estimate of the number of different confined processes:

~]# seinfo -adomain -x | wc -l 550

Not all domain types are confined. To look at the number of unconfined domains, use the unconfined_domain attribute:

~]# seinfo -aunconfined_domain_type -x | wc -l 52

Permissive domains can be counted with the --permissive option:

~]# seinfo --permissive -x | wc -l 31

Remove the additional wc -l command in the above commands to see the full lists.

sesearch

You can use the sesearch utility to search for a particular rule in the policy. It is possible to search either policy source files or the binary file. For example:

~]$ sesearch --role_allow -t httpd_sys_content_t Found 20 role allow rules:

allow system_r sysadm_r;
allow sysadm_r system_r;
allow sysadm_r staff_r;
allow sysadm_r user_r;
allow system_r git_shell_r;
allow system_r guest_r;
allow logadm_r system_r;
allow system_r logadm_r;
allow system_r nx_server_r;
allow system_r staff_r;
allow staff_r logadm_r;
allow staff_r sysadm_r;
allow staff_r unconfined_r;
allow staff_r webadm_r;
allow unconfined_r system_r;
allow system_r unconfined_r;
allow system_r user_r;
allow webadm_r system_r;
allow system_r webadm_r;
allow system_r xguest_r;

The sesearch utility can provide the number of allow rules:

~]# sesearch --allow | wc -l 262798

And the number of dontaudit rules:

~]# sesearch --dontaudit | wc -l 156712

4.12. Prioritizing and Disabling SELinux Policy Modules

The SELinux module storage in /etc/selinux/ allows using a priority on SELinux modules. Enter the following command as root to show two module directories with a different priority:

~]# ls /etc/selinux/targeted/active/modules 100 400 disabled

While the default priority used by semodule utility is 400, the priority used in selinux-policy packages is 100, so you can find most of the SELinux modules installed with the priority 100.

You can override an existing module with a modified module with the same name using a higher priority. When there are more modules with the same name and different priorities, only a module with the highest priority is used when the policy is built.

Example 4.1. Using SELinux Policy Modules Priority

Prepare a new module with modified file context. Install the module with the semodule -i command and set the priority of the module to 400. We use sandbox.pp in the following example.

~]# semodule -X 400 -i sandbox.pp ~]# semodule --list-modules=full | grep sandbox 400 sandbox pp 100 sandbox pp

To return back to the default module, enter the semodule -r command as root:

~]# semodule -X 400 -r sandbox libsemanage.semanage_direct_remove_key: sandbox module at priority 100 is now active.

Disabling a System Policy Module

To disable a system policy module, enter the following command as root:

semodule -d MODULE_NAME

Warning

If you remove a system policy module using the semodule -r command, it is deleted on your system's storage and you cannot load it again. To avoid unnecessary reinstallations of the selinux-policy-targeted package for restoring all system policy modules, use the semodule -d command instead.

4.13. Multi-Level Security (MLS)

The Multi-Level Security technology refers to a security scheme that enforces the Bell-La Padula Mandatory Access Model. Under MLS, users and processes are called subjects, and files, devices, and other passive components of the system are called objects. Both subjects and objects are labeled with a security level, which entails a subject's clearance or an object's classification. Each security level is composed of a sensitivity and a category, for example, an internal release schedule is filed under the internal documents category with a confidential sensitivity.

Figure 4.1, “Levels of clearance” shows levels of clearance as originally designed by the US defense community. Relating to our internal schedule example above, only users that have gained the confidential clearance are allowed to view documents in the confidential category. However, users who only have the confidential clearance are not allowed to view documents that require higher levels or clearance; they are allowed read access only to documents with lower levels of clearance, and write access to documents with higher levels of clearance.

Figure 4.1. Levels of clearance

Figure 4.2, “Allowed data flows using MLS” shows all allowed data flows between a subject running under the "Secret" security level and various objects with different security levels. In simple terms, the Bell-LaPadula model enforces two properties: no read up and no write down.

Figure 4.2. Allowed data flows using MLS

4.13.1. MLS and System Privileges

MLS access rules are always combined with conventional access permissions (file permissions). For example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block access to a file by other users, this also blocks access by users with a security level of "Top Secret". It is important to remember that SELinux MLS policy rules are checked after DAC rules. A higher security clearance does not automatically give permission to arbitrarily browse a file system.

Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they may have access to all information on the computer, this is different from having administrative rights.

4.13.2. Enabling MLS in SELinux

Note

It is not recommended to use the MLS policy on a system that is running the X Window System.

Follow these steps to enable the SELinux MLS policy on your system.

Procedure 4.19. Enabling SELinux MLS Policy# Install the selinux-policy-mls package:


~]# yum install selinux-policy-mls

1. Before the MLS policy is enabled, each file on the file system must be relabeled with an MLS label. When the file system is relabeled, confined domains may be denied access, which may prevent your system from booting correctly. To prevent this from happening, configure SELINUX=permissive in the /etc/selinux/config file. Also, enable the MLS policy by configuring SELINUXTYPE=mls. Your configuration file should look like this:
   

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=mls

1. Make sure SELinux is running in permissive mode:
   

~]# setenforce 0





~]$ getenforce
Permissive

1. Use the fixfiles script to create the /.autorelabel file containing the -F option to ensure that files are relabeled upon next reboot:
   

~]# fixfiles -F onboot

1. Reboot your system. During the next boot, all file systems will be relabeled according to the MLS policy. The label process labels all files with an appropriate SELinux context:
   

*** Warning -- SELinux mls policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
***********


Each * (asterisk) character on the bottom line represents 1000 files that have been labeled. In the above example, eleven * characters represent 11000 files which have been labeled. The time it takes to label all files depends upon the number of files on the system, and the speed of the hard disk drives. On modern systems, this process can take as little as 10 minutes. Once the labeling process finishes, the system will automatically reboot.

1. In permissive mode, SELinux policy is not enforced, but denials are still logged for actions that would have been denied if running in enforcing mode. Before changing to enforcing mode, as root, enter the following command to confirm that SELinux did not deny actions during the last boot. If SELinux did not deny actions during the last boot, this command does not return any output. See Chapter 11, Troubleshooting for troubleshooting information if SELinux denied access during boot.
   

~]# grep "SELinux is preventing" /var/log/messages

1. If there were no denial messages in the /var/log/messages file, or you have resolved all existing denials, configure SELINUX=enforcing in the /etc/selinux/config file:
   

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=mls

1. Reboot your system and make sure SELinux is running in enforcing mode:
   

~]$ getenforce
Enforcing


and the MLS policy is enabled:


~]# sestatus |grep mls
Policy from config file: mls

4.13.3. Creating a User With a Specific MLS Range

Follow these steps to create a new Linux user with a specific MLS range:

Procedure 4.20. Creating a User With a Specific MLS Range# Add a new Linux user using the useradd command and map the new Linux user to an existing SELinux user (in this case, staff_u):


~]# useradd -Z staff_u john

1. Assign the newly-created Linux user a password:
   

prompt~]# passwd john

1. Enter the following command as root to view the mapping between SELinux and Linux users. The output should be as follows:
   

~]# semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ user_u s0-s0 *
john staff_u s0-s15:c0.c1023 *
root root s0-s15:c0.c1023 *
staff staff_u s0-s15:c0.c1023 *
sysadm staff_u s0-s15:c0.c1023 *
system_u system_u s0-s15:c0.c1023 *

1. Define a specific range for user john:
   

~]# semanage login --modify --range s2:c100 john

1. View the mapping between SELinux and Linux users again. Note that the user john now has a specific MLS range defined:
   

~]# semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ user_u s0-s0 *
john staff_u s2:c100 *
root root s0-s15:c0.c1023 *
staff staff_u s0-s15:c0.c1023 *
sysadm staff_u s0-s15:c0.c1023 *
system_u system_u s0-s15:c0.c1023 *

1. To correct the label on john's home directory if needed, enter the following command:
   

~]# chcon -R -l s2:c100 /home/john

4.13.4. Setting Up Polyinstantiated Directories

The /tmp and /var/tmp/ directories are normally used for temporary storage by all programs, services, and users. Such setup, however, makes these directories vulnerable to race condition attacks, or an information leak based on file names. SELinux offers a solution in the form of polyinstantiated directories. This effectively means that both /tmp and /var/tmp/ are instantiated, making them appear private for each user. When instantiation of directories is enabled, each user's /tmp and /var/tmp/ directory is automatically mounted under /tmp-inst and /var/tmp/tmp-inst.

Follow these steps to enable polyinstantiation of directories:

Procedure 4.21. Enabling Polyinstantiation Directories# Uncomment the last three lines in the /etc/security/namespace.conf file to enable instantiation of the /tmp, /var/tmp/, and users' home directories:


~]$ tail -n 3 /etc/security/namespace.conf
/tmp /tmp-inst/ level root,adm
/var/tmp /var/tmp/tmp-inst/ level root,adm
$HOME $HOME/$USER.inst/ level

1. Ensure that in the /etc/pam.d/login file, the pam_namespace.so module is configured for session:
   

~]$ grep namespace /etc/pam.d/login
session required pam_namespace.so

1. Reboot your system.

4.14. File Name Transition

The file name transition feature allows policy writers to specify the file name when writing policy transition rules. It is possible to write a rule that states: If a process labeled A_t creates a specified object class in a directory labeled B_t and the specified object class is named objectname, it gets the label C_t. This mechanism provides more fine-grained control over processes on the system.

Without file name transition, there are three possible ways how to label an object: * By default, objects inherit labels from parent directories. For example, if the user creates a file in a directory labeled etc_t, then the file is labeled also etc_t. However, this method is useless when it is desirable to have multiple files within a directory with different labels.

• Policy writers can write a rule in policy that states: If a process with type A_t creates a specified object class in a directory labeled B_t, the object gets the new C_t label. This practice is problematic if a single program creates multiple objects in the same directory where each object requires a separate label. Moreover, these rules provide only partial control, because names of the created objects are not specified.
• Certain applications have SELinux awareness that allow such an application to ask the system what the label of a certain path should be. These applications then request the kernel to create the object with the required label. Examples of applications with SELinux awareness are the rpm package manager, the restorecon utility, or the udev device manager. However, it is not possible to instruct every application that creates files or directories with SELinux awareness. It is often necessary to relabel objects with the correct label after creating. Otherwise, when a confined domain attempts to use the object, AVC messages are returned.

The file name transition feature decreases problems related to incorrect labeling and improves the system to be more secure. Policy writers are able to state properly that a certain application can only create a file with a specified name in a specified directory. The rules take into account the file name, not the file path. This is the basename of the file path. Note that file name transition uses an exact match done by the strcmp() function. Use of regular expressions or wildcard characters is not considered.

Note

File paths can vary in the kernel and file name transition does not use the paths to determine labels. Consequently, this feature only affects initial file creation and does not fix incorrect labels of already created objects.

Example 4.2. Examples of Policy Rules Written with File Name Transition

The example below shows a policy rule with file name transition:

filetrans_pattern(unconfined_t, admin_home_t, ssh_home_t, dir, ".ssh")

This rule states that if a process with the unconfined_t type creates the ~/.ssh/ directory in a directory labeled admin_home_t, the ~/.ssh/ directory gets the label ssh_home_t.

Similar examples of policy rules written with file name transition are presented below:

filetrans_pattern(staff_t, user_home_dir_t, httpd_user_content_t, dir, "public_html") filetrans_pattern(thumb_t, user_home_dir_t, thumb_home_t, file, "missfont.log") filetrans_pattern(kernel_t, device_t, xserver_misc_device_t, chr_file, "nvidia0") filetrans_pattern(puppet_t, etc_t, krb5_conf_t, file, "krb5.conf")

Note

The file name transition feature affects mainly policy writers, but users can notice that instead of file objects almost always created with the default label of the containing directory, some file objects have a different label as specified in policy.

4.15. Disabling ptrace()

The ptrace() system call allows one process to observe and control the execution of another process and change its memory and registers. This call is used primarily by developers during debugging, for example when using the strace utility. When ptrace() is not needed, it can be disabled to improve system security. This can be done by enabling the deny_ptrace Boolean, which denies all processes, even those that are running in unconfined_t domains, from being able to use ptrace() on other processes.

The deny_ptrace Boolean is disabled by default. To enable it, run the setsebool -P deny_ptrace on command as the root user:

~]# setsebool -P deny_ptrace on

To verify if this Boolean is enabled, use the following command:

~]$ getsebool deny_ptrace deny_ptrace --> on

To disable this Boolean, run the setsebool -P deny_ptrace off command as root:

~]# setsebool -P deny_ptrace off

Note

The setsebool -P command makes persistent changes. Do not use the -P option if you do not want changes to persist across reboots.

This Boolean influences only packages that are part of Red Hat Enterprise Linux. Consequently, third-party packages could still use the ptrace() system call. To list all domains that are allowed to use ptrace(), enter the following command. Note that the setools-console package provides the sesearch utility and that the package is not installed by default.

~]# sesearch -A -p ptrace,sys_ptrace -C | grep -v deny_ptrace | cut -d ' ' -f 5

4.16. Thumbnail Protection

The thumbnail icons can potentially allow an attacker to break into a locked machine using removable media, such as USB devices or CDs. When the system detects a removable media, the Nautilus file manager executes the thumbnail driver code to display thumbnail icons in an appropriate file browser even if the machine is locked. This behavior is unsafe because if the thumbnail executables were vulnerable, the attacker could use the thumbnail driver code to bypass the lock screen without entering the password.

Therefore, a new SELinux policy is used to prevent such attacks. This policy ensures that all thumbnail drivers are locked when the screen is locked. The thumbnail protection is enabled for both confined users and unconfined users. This policy affects the following applications: * /usr/bin/evince-thumbnailer

• /usr/bin/ffmpegthumbnailer
• /usr/bin/gnome-exe-thumbnailer.sh
• /usr/bin/gnome-nds-thumbnailer
• /usr/bin/gnome-xcf-thumbnailer
• /usr/bin/gsf-office-thumbnailer
• /usr/bin/raw-thumbnailer
• /usr/bin/shotwell-video-thumbnailer
• /usr/bin/totem-video-thumbnailer
• /usr/bin/whaaw-thumbnailer
• /usr/lib/tumbler-1/tumblerd
• /usr/lib64/tumbler-1/tumblerd

[3] To temporarily revert to the default behavior, as the Linux root user, run the setsebool httpd_can_network_connect_db off command. For changes that persist across reboots, run the setsebool -P httpd_can_network_connect_db off command.

[4] Files in the /etc/selinux/targeted/contexts/files/ directory define contexts for files and directories. Files in this directory are read by the restorecon and setfiles utilities to restore files and directories to their default contexts.

[5] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.

[6] See the matchpathcon(8) manual page for further information about matchpathcon.