Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

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