Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 6. Using Multi-Level Security (MLS)

The Multi-Level Security (MLS) policy uses levels of clearance as originally designed by the US defense community. MLS meets a very narrow set of security requirements based on information management in rigidly controlled environments such as the military.

Using MLS is complex and does not map well to general use-case scenarios.

6.1. Multi-Level Security (MLS)

The Multi-Level Security (MLS) technology classifies data in a hierarchical classification using information security levels, for example:

  • [lowest] Unclassified
  • [low] Confidential
  • [high] Secret
  • [highest] Top secret

By default, the MLS SELinux policy uses 16 sensitivity levels:

  • s0 is the least sensitive.
  • s15 is the most sensitive.

In MLS:

  • Users and processes are called subjects, whose sensitivity level is called clearance.
  • Files, devices, and other passive components of the system are called objects, whose sensitivity level is called classification.

To implement MLS, SELinux uses the Bell-La Padula Model (BLP) model. This model specifies how information can flow within the system based on labels attached to each subject and object.

The basic principle of BLP is “No read up, no write down.” This means that users can only read files at their own sensitivity level and lower, and data can flow only from lower levels to higher levels, and never the reverse.

In the MLS SELinux policy, which is the implementation of MLS on RHEL, we apply a modified principle called Bell-La Padula with write equality. This means that users can read files at their own sensitivity level and lower, but can write only at exactly their own level. This prevents, for example, low-clearance users from writing content into top-secret files.

The security context for a non-privileged user in an MLS environment is, for example:

user_u:user_r:user_t:s1

Where:

user_u
is the SELinux user.
user_r
is the SELinux role.
user_t
is the SELinux type.
s1
is the MLS sensitivity level.

The system always combines MLS access rules with conventional file access permissions. For example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block access to a file by other users, even “Top Secret” users cannot access that file. A high security clearance does not automatically permit a user to browse the entire file system.

Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they may have access to all sensitive information on the system, this is different from having administrative rights.

In addition, administrative rights do not provide access to sensitive information. For example, even when someone logs in as root, they still cannot read top-secret information.

You can further adjust access within an MLS system by using categories. With Multi-Category Security (MCS), you can define categories such as projects or departments, and users will only be allowed to access files in the categories to which they are assigned.

6.2. SELinux roles in MLS

The SELinux policy maps each Linux user to an SELinux user. This allows Linux users to inherit the restrictions of SELinux users.

Important

The MLS policy does not contain the unconfined module, including unconfined users, types, and roles. As a result, users that would be unconfined, including root, cannot access every object and perform every action they could in the targeted policy.

You can tune the permissions for confined users in your SELinux policy according to specific needs by adjusting the booleans in the policy. You can determine the current state of these booleans by using the semanage boolean -l command.

Table 6.1. Roles of SELinux users in MLS

UserDefault roleAdditional roles

guest_u

guest_r

 

xguest_u

xguest_r

 

user_u

user_r

 

staff_u

staff_r

auditadm_r

secadm_r

sysadm_r

system_r

sysadm_u

sysadm_r

 

root

staff_r

auditadm_r

secadm_r

sysadm_r

system_r

system_u

system_r

 

Each SELinux role corresponds to an SELinux type and provides specific access rights.

Table 6.2. Types and access of SELinux roles in MLS

RoleTypeX window systemsu and sudoExecute in home directory and /tmp (default)Networking

guest_r

guest_t

no

no

yes

no

xguest_r

xguest_t

yes

no

yes

web browsers only (Firefox, GNOME Web)

user_r

user_t

yes

no

yes

yes

staff_r

staff_t

yes

only sudo

yes

yes

auditadm_r

auditadm_t

 

yes

yes

yes

secadm_r

secadm_t

 

yes

yes

yes

sysadm_r

sysadm_t

 

yes

yes

yes

In addition, non-login roles dbadm_r, logadm_r, and webadm_r can be used for a subset of administrative tasks. By default, these roles are not associated with any SELinux user.

6.3. Switching the SELinux policy to MLS

Use the following steps to switch the SELinux policy from targeted to Multi-Level Security (MLS).

Important

Red Hat does not recommend to use the MLS policy on a system that is running the X Window System. Furthermore, when you relabel the file system with MLS labels, the system may prevent confined domains from access, which prevents your system from starting correctly. Therefore ensure that you switch SELinux to permissive mode before you relabel the files. On most systems, you see a lot of SELinux denials after switching to MLS, and many of them are not trivial to fix.

Procedure

  1. Install the selinux-policy-mls package:

    # yum install selinux-policy-mls
  2. Open the /etc/selinux/config file in a text editor of your choice, for example:

    # vi /etc/selinux/config
  3. Change SELinux mode from enforcing to permissive and switch from the targeted policy to MLS:

    SELINUX=permissive
    SELINUXTYPE=mls

    Save the changes, and quit the editor.

  4. Before you enable the MLS policy, you must relabel each file on the file system with an MLS label:

    # fixfiles -F onboot
    System will relabel on next boot
  5. Restart the system:

    # reboot
  6. Check for SELinux denials:

    # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

    Because the previous command does not cover all scenarios, see Troubleshooting problems related to SELinux for guidance on identifying, analyzing, and fixing SELinux denials.

  7. After you ensure that there are no problems related to SELinux on your system, switch SELinux back to enforcing mode by changing the corresponding option in /etc/selinux/config:

    SELINUX=enforcing
  8. Restart the system:

    # reboot
Important

If your system does not start or you are not able to log in after you switch to MLS, add the enforcing=0 parameter to your kernel command line. See Changing SELinux modes at boot time for more information.

Also note that in MLS, SSH logins as the root user mapped to the sysadm_r SELinux role differ from logging in as root in staff_r. Before you start your system in MLS for the first time, consider allowing SSH logins as sysadm_r by setting the ssh_sysadm_login SELinux boolean to 1. To enable ssh_sysadm_login later, already in MLS, you must log in as root in staff_r, switch to root in sysadm_r using the newrole -r sysadm_r command, and then set the boolean to 1.

Verification

  1. Verify that SELinux runs in enforcing mode:

    # getenforce
    Enforcing
  2. Check that the status of SELinux returns the mls value:

    # sestatus | grep mls
    Loaded policy name:             mls

Additional resources

  • The fixfiles(8), setsebool(8), and ssh_selinux(8) man pages.

6.4. Establishing user clearance in MLS

After you switch SELinux policy to MLS, you must assign security clearance levels to users by mapping them to confined SELinux users. A user with a given security clearance:

  • Cannot read objects that have a higher sensitivity level.
  • Cannot write to objects at a lower sensitivity level.
  • Can modify objects at a lower sensitivity level, but this increases the object’s classification level to the user’s clearance level.

Prerequisites

  • The SELinux policy is set to mls.
  • The SELinux mode is set to enforcing.
  • The policycoreutils-python-utils package is installed.
  • A user assigned to an SELinux confined user:

    • For a non-privileged user, assigned to user_u.
    • For a privileged user, assigned to staff_u.
Note

Make sure that the users have been created when the MLS policy was active. Users created in other SELinux policies cannot be used in MLS.

Procedure

  1. Optional: To prevent adding errors to your SELinux policy, switch to the permissive SELinux mode, which facilitates troubleshooting:

    # setenforce 0
    Important

    In permissive mode, SELinux does not enforce the active policy but only logs Access Vector Cache (AVC) messages, which can be then used for troubleshooting and debugging.

  2. Define a clearance range for the staff_u SELinux user. For example, this command sets the clearance range from s1 to s15 with s1 being the default clearance level:

    # semanage user -m -L s1 -r s1-s15 staff_u
  3. Generate SELinux file context configuration entries for user home directories:

    # genhomedircon
  4. Restore file security contexts to default:

    # restorecon -R -F -v /home/
    Relabeled /home/staff from staff_u:object_r:user_home_dir_t:s0 to staff_u:object_r:user_home_dir_t:s1
    Relabeled /home/staff/.bash_logout from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
    Relabeled /home/staff/.bash_profile from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
    Relabeled /home/staff/.bashrc from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
  5. Assign a clearance level to the user:

    # semanage login -m -r s1 example_user

    Where s1 is the clearance level assigned to the user.

  6. Relabel the user’s home directory to the user’s clearance level:

    # chcon -R -l s1 /home/example_user
  7. Optional: If you previously switched to the permissive SELinux mode, and after you verify that everything works as expected, switch back to the enforcing SELinux mode:

    # setenforce 1

Verification steps

  1. Verify that the user is mapped to the correct SELinux user and has the correct clearance level assigned:

    # semanage login -l
    Login Name      SELinux User         MLS/MCS Range        Service
    __default__     user_u               s0-s0                *
    example_user    user_u               s1                   *
    ...
  2. Log in as the user within MLS.
  3. Verify that the user’s security level works correctly:

    Important

    The files you use for verification should not contain any sensitive information in case the configuration is incorrect and the user actually can access the files without authorization.

    1. Verify that the user cannot read a file with a higher-level sensitivity.
    2. Attempt to write to a file with a lower-level sensitivity. This should increase the file’s classification level to the user’s clearance level.
    3. Verify that the user can read a file with a lower-level sensitivity.

6.5. Changing file sensitivity in MLS

In the MLS SELinux policy, users can only modify files at their own sensitivity level. This is intended to prevent any highly sensitive information to be exposed to users at lower clearance levels, and also prevent low-clearance users creating high-sensitivity documents. Administrators, however, can manually increase a file’s classification, for example for the file to be processed at the higher level.

Prerequisites

  • SELinux policy is set to mls.
  • SELinux mode is set to enforcing.
  • You have security administration rights, which means that you are assigned to either:

    • The secadm_r role.
    • If the sysadm_secadm module is enabled, to the sysadm_r role. The sysadm_secadm module is enabled by default.
  • The policycoreutils-python-utils package is installed.
  • A user assigned to any clearance level. For additional information, see

Section 6.4, “Establishing user clearance in MLS” .

+ In this example, User1 has clearance level s1. * A file with a classification level assigned and to which you have access.

+ In this example, /path/to/file has classification level s1.

Procedure

  1. Check the file’s classification level:

    # ls -lZ file
    -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s1 0 12. Feb 10:43 /path/to/file
  2. Change the file’s default classification level:

    # semanage fcontext -a -r s2 /path/to/file
  3. Force the relabeling of the file’s SELinux context:

    # restorecon -F -v /path/to/file
    Relabeled /path/to/file from root:object_r:user_home_t:s0 to user_u:object_r:user_home_t:s2

Verification

  1. Check the file’s classification level:

    # ls -lZ file
    -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s2 0 12. Feb 10:53 /path/to/file
  2. Optional: Verify that the lower-clearance user cannot read the file:

    $ cat /path/to/file
    cat: file: Permission denied