Keeping Or Ignoring SELinux Contexts

Now that we are aware that file contexts are stored as extended attributes, how do we ensure that files receive the correct label when they are written or modified? To set an SELinux context on a filesystem resource, a few guidelines exist, ranging from inheritance rules to explicit commands.

Inheriting the default contexts

By default, the SELinuxsecurity subsystem uses context inheritance to identify which context should be assigned to a file (or directory, socket, and so on) when it is created. A file created in a directory with avar_tcontext will be assigned thevar_tcontext as well. This means that the file inherits the context from the parent directory and not from the context of the executing process.

There are a few exceptions to this though:

SELinux-aware applications can force the context of a file to be different (assuming the SELinux policy allows it, of course). As this is within the software code itself, this behavior cannot be generally configured.
An application calledrestorecondcan be used that enforces contexts on various paths/files based on SELinux’s context rules. We will cover these rules and therestorecondapplication in theSELinux file context expressionsandModifying file contextssections, respectively.
The SELinux policy allows for transition rules that consider the context of the process creating new files or directories, as well as the name of the file the process is creating.

It is these transition rules we will cover next.

Querying transition rules

Type transitionrules are policy rules that force the use of a different type upon certain conditions. For file contexts, such a type transition rule can be as follows: if a process running in thehttpd_tdomain creates a file in a directory labeled with thevar_log_tSELinux type, then the type identifier of the file becomeshttpd_log_t.

Basically, this rule assigns thehttpd_log_tweb server log context to any file placed in a log directory by web servers, rather than the defaultvar_log_t, which would be the case when standard inheritance was used.

We can query these type transition rules usingsesearch. Thesesearchapplication is one of the most important tools available to query the current SELinux policy. For the previous example, we need the (source) domain and the (target) context of the directory:httpd_tandvar_log_t. In the following example, we usesesearchto find the type transition declaration related to thehttpd_tdomain toward thevar_log_tcontext:

$ sesearch -T -s httpd_t -t var_log_t
type_transition httpd_t var_log_t:file httpd_log_t;

The type_transition line is an SELinux policy rule, which maps perfectly to the description. Let’s look at another set of type transition rules for the tmp_t type (assigned to the directory used for temporary files, such as /tmp and /var/tmp):

$ sesearch -T -s httpd_t -t tmp_t
type_transition httpd_t tmp_t:dir httpd_tmp_t;
type_transition httpd_t tmp_t:file httpd_tmp_t;
type_transition httpd_t tmp_t:file krb5_host_rcache_t HTTP_23;
type_transition httpd_t tmp_t:file krb5_host_rcache_t HTTP_48;
type_transition httpd_t tmp_t:lnk_file httpd_tmp_t;
type_transition httpd_t tmp_t:sock_file httpd_tmp_t;

The policy tells us that, if a file, directory, symbolic link, or socket is created in a directory labeledtmp_t, thenthis newly created resource gets thehttpd_tmp_tcontext assigned (and thus not the default, inheritedtmp_tone). Alongside these rules, it also contains two named file transitions, which are more flexible transition rules.

Withnamed file transitions, the policy can consider the name of the file (or directory) created toselect a more appropriate context. In the previous example, if a file namedHTTP_23orHTTP_48is created in a directory labeledtmp_t, then it does not get thehttpd_tmp_tcontext assigned (as would be implied by the regular type transition rules), but thekrb5_host_rcache_ttype (used for Kerberos implementations) instead.

Type transitions not only give us insight into what labels (and thus also SELinux contexts) are going to be assigned, but also give us some clues as to which types are related to a particular domain. In the web server example, we found out by querying the policy that its log files are most likely labeledhttpd_log_t, and its temporary fileshttpd_tmp_t.

Copying and moving files

File contexts can also be transferred together with the file itself during copy or move operations. By default, Linux will do the following:

Retain the file context in case of a move (mv) operation on the same filesystem (as this operation does not touch extended attributes, but merely adjusts the metadata of the file).
Ignore the current file context in case of a move operation across a filesystem boundary, as this creates a new file, including content and extended attributes. Instead, it uses the inheritance (or file transition rules) to define the target context.
Ignore the file context in case of a copy (cp) operation, instead using the inheritance (or file transition rules) to define the target context.

Luckily, this is just default behavior (based on the extended attribute support of these utilities) that can be manipulated freely.

We can use the-Zoption to tellmvthat the context of the file should be set to the default type associated with the target location. For instance, in the next example, two files are moved froma user’s home directory to the/srvdirectory. Thefirst example will retain its file context (user_home_toradmin_home_t), while the second one will receive the type associated with user files placed in/srv(var_t):

# touch test1 test2
# mv test1 /srv
# mv -Z test2 /srv
# ls -Z /srv/test*
staff_u:object_r:admin_home_t:s0 /srv/test1
staff_u:object_r:var_t:s0 /srv/test2

Similarly, we can tell the cp command through the --preserve=context option to preserve the SELinux context while copying files. Using the same example, we now get the following:

# cp test1 /srv
# cp --preserve=context test2 /srv
# ls -Z /srv/test*
staff_u:object_r:var_t:s0 /srv/test1
staff_u:object_r:admin_home_t:s0 /srv/test2

Most of the utilities provided through the coreutils package support the -Z option: mkdir (to create a directory), mknod (to create a device file), mkfifo (to create a named pipe), and so on.

Note:

If the mv command returns failed to set the security context when using the -Z option, then it is very likely that the location either does not have a valid context associated with it, or that the filesystem does not support SELinux labels. The former is for instances applicable when moving files to /tmp as the CentOS SELinux policy does not have any default context set for files and directories inside /tmp. Newly created resources always need to have their own affiliated labels applied (such as user_tmp_t).

Even more so, many of these utilities allow the user to explicitly provide a context through the --context option. For instance, to create a directory, /srv/foo, with the context user_home_t, using mkdir by default would not work, as the target context would be set to var_t. With the --context option, we can tell the utility to set a specific context:

# mkdir --context=user_u:object_r:user_home_t:s0 /srv/foo
# ls -dZ /srv/foo
user_u:object_r:user_home_t:s0 /srv/foo

For other utilities, it is best to consult the manual page and see how the utility deals with extended attributes. For instance, the rsync command can preserve the extended attributes by using the -X or --xattrs option.

Temporarily changing file contexts

We can use the chcon tool to update the context of the file (or files) directly. In our previous example, we noticed the var_t label on the DokuWiki files. This is a generic type for variable data and is not the right context for web content. We can use chcon to put the httpd_sys_content_t label on these files, which would allow web servers to have read access on these resources:

# chcon -R -t httpd_sys_content_t /srv/web

Another feature that chcon offers is to tell it to label a file or location with the same context as a different file. In the next example, we use chcon to label /srv/web and its resources with the same context as used for the /var/www directory:

$ chcon -R --reference /var/www /srv/www

If we change the context of a file throughchconand set it to a context different from the one in the context list, then the context might be reverted later: package managers might reset the file contexts back to their intended value, or the system administrator might trigger a fill filesystem relabeling operation.

Until now, we’ve only focused on the type part of a context. Contexts, however, also include a role part and an SELinux user part. If UBAC is not enabled, then the SELinux user has no influence on any decisions, and resetting it has little value. If UBAC is enabled, though, it might be necessary to reset the SELinux user values on files. Utilities such aschconcan set the SELinux user as well:

# chcon -u system_u -R /srv/web

The role for a file is usuallyobject_ras roles currently only make sense for users (processes).

To be able to change contexts, we do need the proper SELinux privileges, namedrelabelfromandrelabelto. These rights are granted on domains to indicate whether the domain canchange a label from one type to another. If we find denials in the audit log related to these permissions, then this means that the policy prohibits the domain from changing the contexts.

Placing categories on files and directories

We focused primarily on changing types and briefly touched SELinux users, but another important part is to support categories and sensitivity levels. With chcon, we can add sensitivity levels and categories as follows:

# chcon -l s0:c0,c2 doku.php

Another tool that can be used to assign categories is the chcat tool. With chcat, we can assign additional categories rather than having to reiterate them, as would be the case with chcon, and even enjoy the human-readable category levels provided by the setrans.conf file:

# chcat -- +Contracts doku.php

To remove a category, just use the minus sign:

# chcat -- -Contracts doku.php

To remove all categories, use the -d option:

# chcat -d doku.php

Users and administrators should keep in mind that applications generally do not set categories themselves, so they need to be added ad hoc.

Using multilevel security on files

When the system uses an MLS policy, the chcon tool needs to be used. The syntax is the same as with categories. For instance, to set the sensitivity s1 and category set c2 and c4 to c10 on all files of a user’s home directory, you’d do the following:

$ chcon -R -l s1:c2,c4.c10 /home/lisa

Remember that both the context of the user executing chcon and the context of the user who will use the data must be able to deal with the mentioned sensitivity.

Backing up and restoring extended attributes

As with the regular file operation tools (such as mv and cp), backup software, too, needs to consider SELinux contexts. Two important requirements exist for a backup tool when working with SELinux-enabled systems:

The backup tool must run in an SELinux context capable of reading all files in scope of the backup, and, of course, of restoring those files as well. If no specific SELinux policy for the backup tool exists, then it might need to run in an unconfined or highly privileged domain to succeed.
The backup tool must be able to back up and restore extended attributes.

A popular tool for taking backups (or archives) is the tar application, which supports SELinux contexts as follows:

# tar cjvf dokuwiki-20200405.tar.bz2 /srv/web --selinux

When creating a tar archive, add --selinux to include SELinux contexts (both during the creation of the archive and when extracting files from the archive).

Using mount options to set SELinux contexts

Not allfilesystems support extended attributes. When we use a filesystem without extended attribute support, then the SELinux context of a file is either based on the filesystem type itself (each filesystem has its own associated context) or is passed on to the system using amountoption.

The most commonly usedmountoption in these situations is thecontext=option. When set, it will use the mentioned context as the context for all the resources in the filesystem. For instance, to mount an external USB drive that hosts a FAT filesystem while ensuring that end users can write to it, we could mount it with theuser_home_tcontext:

# mount -o context="user_u:object_r:user_home_t:s0" /dev/sdc1 /media/usb

If the filesystem supports extended attributes but doesn’t have all files labeled yet, then we can use the defcontext= option to tell Linux that, if no SELinux context is available, then the default context provided should be used:

# mount -o defcontext="system_u:object_r:var_t:s0" /dev/sdc1 /srv/backups

Another mount option isfscontext=. This assigns a context on the filesystem type rather than the context of the files on the filesystem. For instance, a CD/DVD filesystem can be ISO 9660, Joliet, or UDF. SELinux uses this type definition on a filesystem to map permissions such as mount operations and file creation. With thefscontext=option, the filesystem type can be set differently from what the default filesystem type would be.

The last option that can be used when mounting filesystems is therootcontext=option. This will force the root inode of the filesystem to have the given context even before the filesystemis visible to the user space. Permission checks on the location during the mount operation itself can cause havoc when the location does not have the expected context (especially when filesystems are mounted outside their expected location). Therootcontext=option provides a reusable configuration option to set the expected context:

# mount -o rootcontext="system_u:object_r:tmp_t:s0" -t tmpfs none /var/tmp

That’s it – these are all the context-related mount options. A final note though: the context= option is mutually exclusive to the defcontext= and fscontext= options. So, while the defcontext= and fscontext= options can be used together, they cannot be used with the context= option. Assuming the target filesystem allows for extended attributes, then we can use the file context expressions, which we will cover in the next section.