Chapter 6. Using Multi-Level Security (MLS)

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

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

Procedure

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

   # setenforce 0

   Note that 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

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:

   Warning

   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. Verify that the user can write to a file with the same sensitivity.
   3. Verify that the user can read a file with a lower-level sensitivity.

Procedure

1. Log in as the user from a secure terminal.

   Secure terminals are defined in the /etc/selinux/mls/contexts/securetty_types file. By default, the console is a secure terminal, but SSH is not.

2. Check the current user’s security context:

   $ id -Z
   user_u:user_r:user_t:s0-s2

   In this example, the user is assigned to the user_u SELinux user, user_r role, user_t type, and the MLS security range s0-s2.

3. Check the current user’s security context:

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. Switch to a different security clearance range within the user’s clearance range:

   $ newrole -l s1

   You can switch to any range whose maximum is lower or equal to your assigned range. Entering a single-level range changes the lower limit of the assigned range. For example, entering newrole -l s1 as a user with a s0-s2 range is equivalent to entering newrole -l s1-s2.

Verification

1. Display the current user’s security context:

   $ id -Z
   user_u:user_r:user_t:s1-s2

2. Return to the previous shell with the original range by terminating the current shell:

   $ exit

Procedure

1. Optional: Display the security context of the current user:

   $ id -Z
   user_u:user_r:user_t:s0-s2

2. Change the lower level of the user’s MLS clearance range to the level which you want to assign to the file:

   $ newrole -l s1-s2

3. Optional: Display the security context of the current user:

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. Optional: Display the security context of the file:

   $ ls -Z /path/to/file
   user_u:object_r:user_home_t:s0 /path/to/file

5. Change the file’s sensitivity level to the lower level of the user’s clearance range by modifying the file:

   $ touch /path/to/file

   Important

   The classification level reverts to the default value if the restorecon command is used on the system.

6. Optional: Exit the shell to return to the user’s previous security range:

   $ exit

Procedure

1. Check the file’s classification level:

   # ls -lZ /path/to/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 user_u:object_r:user_home_t:s1 to user_u:object_r:user_home_t:s2

Verification

1. Check the file’s classification level:

   # ls -lZ /path/to/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

Procedure

1. Create a new sudoers file in the /etc/sudoers.d directory for the user:

   # visudo -f /etc/sudoers.d/<sec_adm_user>

   To keep the sudoers files organized, replace <sec_adm_user> with the Linux user which will be assigned to the secadm role.

2. Add the following content into the /etc/sudoers.d/<sec_adm_user> file:

   <sec_adm_user> ALL=(ALL) TYPE=secadm_t ROLE=secadm_r ALL

   This line authorizes <secadmuser> on all hosts to perform all commands, and maps the user to the secadm SELinux type and role by default.

3. Log in as the <sec_adm_user> user.

   To make sure that the SELinux context (which consists of SELinux user, role, and type) is changed, log in using ssh, the console, or xdm. Other ways, such as su and sudo, cannot change the entire SELinux context.

4. Verify the user’s security context:

   $ id
   uid=1000(<sec_adm_user>) gid=1000(<sec_adm_user>) groups=1000(<sec_adm_user>) context=staff_u:staff_r:staff_t:s0-s15:c0.c1023

5. Run the interactive shell for the root user:

   $ sudo -i
   [sudo] password for <sec_adm_user>:

6. Verify the current user’s security context:

   # id
   uid=0(root) gid=0(root) groups=0(root) context=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023

7. Disable the sysadm_secadm module from the policy:

   # semodule -d sysadm_secadm

   Important

   Use the semodule -d command instead of removing the system policy module by using the semodule -r command. The semodule -r command deletes the module from your system’s storage, which means it cannot be loaded again without reinstalling the selinux-policy-mls package.

Verification

1. As the user assigned to the secadm role, and in the interactive shell for the root user, verify that you can access the security policy data:

   # seinfo -xt secadm_t
   
   Types: 1
      type secadm_t, can_relabelto_shadow_passwords, (…) userdomain;

2. Log out from the root shell:

   # logout

3. Log out from the <sec_adm_user> user:

   $ logout
   Connection to localhost closed.

4. Display the current security context:

   # id
   uid=0(root) gid=0(root) groups=0(root) context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023

5. Attempt to enable the sysadm_secadm module. The command should fail:

   # semodule -e sysadm_secadm
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   semodule:  Failed!

6. Attempt to display the details about the sysadm_t SELinux type. The command should fail:

   # seinfo -xt sysadm_t
   [Errno 13] Permission denied: '/sys/fs/selinux/policy'

Procedure

1. Determine the current terminal type:

   # ls -Z `tty`
   root:object_r:user_devpts_t:s0 /dev/pts/0

   In this example output, user_devpts_t is the current terminal type.

2. Add the relevant SELinux type on a new line in the /etc/selinux/mls/contexts/securetty_types file.

3. Optional: Switch SELinux to enforcing mode:

   # setenforce 1

Procedure

1. Optional: Switch to permissive mode for easier troubleshooting.

   # setenforce 0

2. Open a new .cil file with a text editor, for example ~/local_mlsfilewrite.cil, and insert the following custom rule:

   (typeattributeset mlsfilewrite (_staff_t_))

   You can replace staff_t with a different SELinux type. By specifying SELinux type here, you can control which SELinux roles can edit lower-level files.

   To keep your local modules better organized, use the local_ prefix in the names of local SELinux policy modules.

3. Install the policy module:

   # semodule -i ~/local_mlsfilewrite.cil

   Note

   To remove the local policy module, use semodule -r ~/local_mlsfilewrite. Note that you must refer to the module name without the .cil suffix.

4. Optional: If you previously switched back to permissive mode, return to enforcing mode:

   # setenforce 1

Verification

1. Find the local module in the list of installed SELinux modules:

   # semodule -lfull | grep "local_mls"
   400 local_mlsfilewrite  cil

   Because local modules have priority 400, you can list them also by using the semodule -lfull | grep -v ^100 command.

2. Log in as a user assigned to the type defined in the custom rule, for example, staff_t.

3. Attempt to write to a file with a lower sensitivity level. This increases the file’s classification level to the user’s clearance level.

   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.