SELinux file contexts are 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.
Let’s look at the current context of the
dokuwiki directory itself:
# ls -dZ /srv/web/localhost/htdocs/dokuwiki undefined_u:object_r:var_t:s0 /srv/web/localhost/htdocs/dokuwiki
The context displayed here is
var_t. In the Keeping or ignoring contexts section, we will change this to the correct context (as
var_t is too generic and not meant for hosting web content).
File and directory contexts are stored in the filesystem as extended attributes when the filesystem supports this. An extended attribute (often abbreviated to xattr) 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 a label to 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:
The namespace of an extended attribute allows for additional access controls or features. Of the currently supported extended attribute namespaces (
security namespace enforces specific restrictions on manipulating the attribute: if no security module is loaded (for instance, SELinux is not enabled), then only processes with the
CAP_SYS_ADMIN capability (basically root or similarly privileged processes) can modify this parameter.
We can query the existing extended attributes using the
getfattr application, 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, the
security.selinux extended attribute hosts the SELinux context. This ensures that non-administrative users cannot alter the SELinux context of a file when SELinux is disabled and that the SELinux policy controls who can manipulate contexts when SELinux is enabled.
stat application 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 (
Interpreting SELinux context types
After using SELinux 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
/tmp for a Java application (
java_tmp_t), or a socket of
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
/bin folder (and
/usr/bin) to be associated with the
bin_t type, boot files in
/boot associated with
boot_t, and generic system resources in
/usr associated with
postgresql_tcontext is meant for the application itself (process type or domain).
postgresql_port_tcontext is meant for the TCP port on which the PostgreSQL daemon listens.
postgresql_client_packet_tcontexts are types associated with network packets received (in case of the
postgresql_server_packet_ttype) or sent to the PostgreSQL port.
postgresql_exec_ttype is assigned to the
- The various
postgresql_*_ttypes for specific filesystem locations related to the daemon, such as
postgresql_var_run_t(to apply to resources in
postgresql_etc_t(to apply to resources in
postgresql_log_t(to apply to resources in
postgresql_tmp_t(to apply to resources in
mysqld_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 the
user_home_t context as extended attributes are moved with it. As the web server process isn’t allowed to access
user_home_t by 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.