Introduction to SELinux File Contexts

SELinux file contextsare the most important configuration that a system administrator will have to work with when working with SELinux on the system. Contexts for files are generally identified through a label that is assigned to the file. Mislabeled files are a constant source of headaches for sysadmins, and most common SELinux issues are resolved by correcting the SELinux context.

Knowing where and how SELinux contexts are used is key to understanding and resolving SELinux related issues. The following diagram shows how contexts are applied on regular Linux resources, and how the LSM subsystem uses these contexts for decision making:

Let’s consider a web-based deployment as an example: DokuWiki. This is a popular PHP wiki that uses files rather than a database as its backend system, and is easy to install and manage. As a web hosting platform, we will use nginx.

Getting context information

Let’s assume that the DokuWiki application will be hosted at /srv/web/localhost/htdocs/dokuwiki and that it will store its wiki pages (user content) in the data/ subdirectory. We start by downloading the latest DokuWiki tarball from the project site, http://download.dokuwiki.org, and extract it to this location:

# mkdir -p /srv/web/localhost/htdocs/
# tar -C /srv/web/localhost/htdocs/ -xvf dokuwiki.tgz
# chown -R nginx:nginx /srv/web/localhost/htdocs/dokuwiki

While distributions might have prepackaged DokuWiki installations available, we will use the manual installation approach to show the various file context-related actions in this chapter.

The contexts of files can easily be acquired using the-Zoption of thelscommand. Most utilitiesthat can provide feedback on contexts will try to do so using the-Zoption.

Let’s look at the current context of thedokuwikidirectory itself:

# ls -dZ /srv/web/localhost/htdocs/dokuwiki
undefined_u:object_r:var_t:s0 /srv/web/localhost/htdocs/dokuwiki

The context displayed here isvar_t. In theKeeping or ignoring contextssection, we will change this to the correct context (asvar_tis too generic and not meant for hosting web content).

File and directory contexts are stored in the filesystem as extended attributes when the filesystemsupports this. Anextended attribute(often abbreviated toxattr) is a key/value combination associated with a resource’s inode (an information block that represents a file, directory, or symbolic link on a filesystem). Each resource can have multiple extended attributes, but only one value per unique key. When we talk about assigning alabelto a file or directory (or relabeling a file), then we imply setting or updating this extended attribute, as it is the label that SELinux will use to obtain the SELinux context for the file.

By convention, extended attributes on Linux use the following syntax:

<namespace>.<attribute>=<value>

The namespace of an extended attribute allows for additional access controls or features. Of the currently supported extended attribute namespaces (security,system,trusted, anduser), thesecuritynamespace enforces specific restrictions on manipulating the attribute: if no security module is loaded (for instance, SELinux is not enabled), then only processes with theCAP_SYS_ADMINcapability (basically root or similarly privileged processes) can modify this parameter.

We can query the existing extended attributes using thegetfattrapplication, as shown in the following example:

$ getfattr -m . -d dokuwiki
# file: dokuwiki
security.selinux="unconfined_u:object_r:var_t:s0"

As we can see, thesecurity.selinuxextended attribute hosts the SELinux context. This ensures that non-administrative users cannot alter the SELinux context of a file when SELinux isdisabled and that the SELinux policy controls who can manipulate contexts when SELinux is enabled.

Thestatapplication can also be used to show SELinux contexts:

$ stat dokuwiki
 File: dokuwiki
 Size: 211		Blocks: 0		IO Block: 4096	
directory
Device: fd01h/64769d	Inode: 8512888	Links: 8
Access: (0755/drwxr-xr-x)	Uid: (	0/	root) Gid: (	0/	root)
Context: unconfined_u:object_r:var_t:s0
...

Getting context information from a file or directory should be as common to an administrator as getting regular access control information (the read (r), write (w), and execute (x) flags).

Interpreting SELinux context types

After usingSELinux for a while, the motive behind using file labels to assign an SELinux context to the file becomes somewhat clearer. SELinux contexts are named after their purpose, allowing administrators to more easily see whether a context is correctly assigned.

Consider the context of a user file in its home directory (user_home_t), a directory in/tmpfor a Java application (java_tmp_t), or a socket ofrpcbind(rpcbind_var_run_t). All these files or directories have considerably different purposes on the filesystem, and this reflects itself in the assigned contexts.

Policy writers will always try to name the context consistently, making it easier for us to understand the purpose of the file, but also to make the policy almost self-explanatory so that administrators can understand the purpose of the policy without additional documentation needs.

For the regular filesystem, for instance, files are labeled with a context resembling their main location as they have similar security properties. For example, we find binaries in the/binfolder (and/usr/bin) to be associated with thebin_ttype, boot files in/bootassociated withboot_t, and generic system resources in/usrassociated withusr_t.

We canalso find more application-specific contexts. For instance, for the PostgreSQL database server, we have the following:

• Thepostgresql_tcontext is meant for the application itself (process type or domain).
• Thepostgresql_port_tcontext is meant for the TCP port on which the PostgreSQL daemon listens.
• Thepostgresql_server_packet_tandpostgresql_client_packet_tcontexts are types associated with network packets received (in case of thepostgresql_server_packet_ttype) or sent to the PostgreSQL port.
• Thepostgresql_exec_ttype is assigned to thepostgresbinary.
• The variouspostgresql_*_ttypes for specific filesystem locations related to the daemon, such aspostgresql_var_run_t(to apply to resources in/var/run),postgresql_etc_t(to apply to resources in/etc),postgresql_log_t(to apply to resources in/var/log), andpostgresql_tmp_t(to apply to resources in/tmp).
• Themysqld_db_ttype for the database files themselves.

Based on the context of a file or resource, administrators can easily detect anomalies in the system setup. An example of an anomaly is when we move a file from the user’s home directory to a web server location. When this occurs, the file retains theuser_home_tcontext as extended attributes are moved with it. As the web server process isn’t allowed to accessuser_home_tby default, it will not be able to serve this file to its users.

Let’s see how to properly set contexts during such copy or move operations.