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 around the way information are managed in rigidly controlled environments such as the military.

MLS is difficult to work with and does not map well to general-case scenarios.

6.1. Multi-Level Security (MLS)

The Multi-Level Security (MLS) technology classifies data using the information security levels:

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

The rules that apply to data flow operate from lower levels to higher levels, and never the reverse.

MLS calls processes as subjects, and files, devices, and other passive components of the system as objects. Both subjects and objects are labeled with a security level, which entails a subject’s clearance or an object’s classification.

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. In BLP, processes can read the same or lower security levels but can only write to the same or higher security level.

The system always combines MLS access rules with conventional access permissions (file 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, this also blocks access by users with a security level of "Top Secret". A higher security clearance does not automatically permit to arbitrarily browse a file system.

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

6.2. Switching the SELinux policy to MLS

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


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.


  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:


    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:

  8. Restart the system:

    # reboot

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 steps

  1. Verify that SELinux runs in enforcing mode:

    # getenforce
  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.