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_t
context will be assigned thevar_t
context 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 called
restorecond
can be used that enforces contexts on various paths/files based on SELinux’s context rules. We will cover these rules and therestorecond
application 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_t
domain creates a file in a directory labeled with thevar_log_t
SELinux type, then the type identifier of the file becomeshttpd_log_t
.
Basically, this rule assigns thehttpd_log_t
web 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
. Thesesearch
application 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_t
andvar_log_t
. In the following example, we usesesearch
to find the type transition declaration related to thehttpd_t
domain toward thevar_log_t
context:
$ 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_t
context assigned (and thus not the default, inheritedtmp_t
one). 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_23
orHTTP_48
is created in a directory labeledtmp_t
, then it does not get thehttpd_tmp_t
context assigned (as would be implied by the regular type transition rules), but thekrb5_host_rcache_t
type (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-Z
option to tellmv
that 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/srv
directory. Thefirst example will retain its file context (user_home_t
oradmin_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 throughchcon
and 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 aschcon
can set the SELinux user as well:
# chcon -u system_u -R /srv/web
The role for a file is usuallyobject_r
as roles currently only make sense for users (processes).
To be able to change contexts, we do need the proper SELinux privileges, namedrelabelfrom
andrelabelto
. 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 amount
option.
The most commonly usedmount
option 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_t
context:
# 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.