Procedure

1. Open the /etc/selinux/config file in a text editor of your choice, for example:

   # vi /etc/selinux/config

2. Configure the SELINUX=permissive option:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=permissive
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. Restart the system:

   # reboot

Verification

1. After the system restarts, confirm that the getenforce command returns Permissive:

   $ getenforce
   Permissive

Procedure

1. Open the /etc/selinux/config file in a text editor of your choice, for example:

   # vi /etc/selinux/config

2. Configure the SELINUX=enforcing option:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=enforcing
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. Save the change, and restart the system:

   # reboot

   On the next boot, SELinux relabels all the files and directories within the system and adds SELinux context for files and directories that were created when SELinux was disabled.

Verification

1. After the system restarts, confirm that the getenforce command returns Enforcing:

   $ getenforce
   Enforcing

Procedure

1. Enable SELinux in permissive mode. For more information, see Changing to permissive mode.

2. Restart your system:

   # reboot

3. Check for SELinux denial messages.For more information, see Identifying SELinux denials.

4. Ensure that files are relabeled upon the next reboot:

   # fixfiles -F onboot

   This creates the /.autorelabel file containing the -F option.

   Warning

   Always switch to permissive mode before entering the fixfiles -F onboot command. This prevents the system from failing to boot in case the system contains unlabeled files. For more information, see RHBZ#2021835.

5. If there are no denials, switch to enforcing mode. For more information, see Changing SELinux modes at boot time.

Verification

1. After the system restarts, confirm that the getenforce command returns Enforcing:

   $ getenforce
   Enforcing

Procedure

1. Open the /etc/selinux/config file in a text editor of your choice, for example:

   # vi /etc/selinux/config

2. Configure the SELINUX=disabled option:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=disabled
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. Save the change, and restart your system:

   # reboot

Verification

1. After reboot, confirm that the getenforce command returns Disabled:

   $ getenforce
   Disabled

Procedure

1. Enter the following command to create a new Linux user named example.user:

   # useradd example.user

2. To assign a password to the Linux example.user user:

   # passwd example.user
   Changing password for user example.user.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. Log out of your current session.
4. Log in as the Linux example.user user. When you log in, the pam_selinux PAM module automatically maps the Linux user to an SELinux user (in this case, unconfined_u), and sets up the resulting SELinux context. The Linux user’s shell is then launched with this context.

Verification

1. When logged in as the example.user user, check the context of a Linux user:

   $ id -Z
   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Procedure

1. Enter the following command to create a new Linux user named example.user and map it to the SELinux staff_u user:

   # useradd -Z staff_u example.user

2. To assign a password to the Linux example.user user:

   # passwd example.user
   Changing password for user example.user.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. Log out of your current session.
4. Log in as the Linux example.user user. The user’s shell launches with the staff_u context.

Verification

1. When logged in as the example.user user, check the context of a Linux user:

   $ id -Z
   uid=1000(example.user) gid=1000(example.user) groups=1000(example.user) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023

Procedure

1. Display the list of SELinux login records. The list displays the mappings of Linux users to SELinux users:

   # semanage login -l
   
   Login Name    SELinux User  MLS/MCS Range   Service
   
   __default__   unconfined_u  s0-s0:c0.c1023       *
   root          unconfined_u  s0-s0:c0.c1023       *

2. Map the __default__ user, which represents all users without an explicit mapping, to the user_u SELinux user:

   # semanage login -m -s user_u -r s0 __default__

Verification

1. Check that the __default__ user is mapped to the user_u SELinux user:

   # semanage login -l
   
   Login Name    SELinux User   MLS/MCS Range    Service
   
   __default__   user_u         s0               *
   root          unconfined_u   s0-s0:c0.c1023   *

2. Verify that the processes of a new user run in the user_u:user_r:user_t:s0 SELinux context.

   1. Create a new user:

      # adduser example.user

   2. Define a password for example.user:

      # passwd example.user

   3. Log out as root and log in as the new user.

   4. Show the security context for the user’s ID:

      [example.user@localhost ~]$ id -Z
      user_u:user_r:user_t:s0

   5. Show the security context of the user’s current processes:

      [example.user@localhost ~]$ ps axZ
      LABEL                           PID TTY      STAT   TIME COMMAND
      -                                 1 ?        Ss     0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
      -                              3729 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3907 ?        Ss     0:00 /usr/lib/systemd/systemd --user
      -                              3911 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3918 ?        S      0:00 sshd: example.user@pts/0
      user_u:user_r:user_t:s0        3922 pts/0    Ss     0:00 -bash
      user_u:user_r:user_dbusd_t:s0  3969 ?        Ssl    0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
      user_u:user_r:user_t:s0        3971 pts/0    R+     0:00 ps axZ

Procedure

1. Optional: To allow sysadm_u users to connect to the system using SSH:

   # setsebool -P ssh_sysadm_login on

2. Create a new user, add the user to the wheel user group, and map the user to the sysadm_u SELinux user:

   # adduser -G wheel -Z sysadm_u example.user

3. Optional: Map an existing user to the sysadm_u SELinux user and add the user to the wheel user group:

   # usermod -G wheel -Z sysadm_u example.user

Verification

1. Check that example.user is mapped to the sysadm_u SELinux user:

   # semanage login -l | grep example.user
   example.user     sysadm_u    s0-s0:c0.c1023   *

2. Log in as example.user, for example, using SSH, and show the user’s security context:

   [example.user@localhost ~]$ id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

3. Switch to the root user:

   $ sudo -i
   [sudo] password for example.user:

4. Verify that the security context remains unchanged:

   # id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

5. Try an administrative task, for example, restarting the sshd service:

   # systemctl restart sshd

   If there is no output, the command finished successfully.

   If the command does not finish successfully, it prints the following message:

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

Procedure

1. Create a new user, add the user to the wheel user group, and map the user to the staff_u SELinux user:

   # adduser -G wheel -Z staff_u example.user

2. Optional: Map an existing user to the staff_u SELinux user and add the user to the wheel user group:

   # usermod -G wheel -Z staff_u example.user

3. To allow example.user to gain the SELinux administrator role, create a new file in the /etc/sudoers.d/ directory, for example:

   # visudo -f /etc/sudoers.d/example.user

4. Add the following line to the new file:

   example.user ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

Verification

1. Check that example.user is mapped to the staff_u SELinux user:

   # semanage login -l | grep example.user
   example.user     staff_u    s0-s0:c0.c1023   *

2. Log in as example.user, for example, using SSH, and switch to the root user:

   [example.user@localhost ~]$ sudo -i
   [sudo] password for example.user:

3. Show the root security context:

   # id -Z
   staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

4. Try an administrative task, for example, restarting the sshd service:

   # systemctl restart sshd

   If there is no output, the command finished successfully.

   If the command does not finish successfully, it prints the following message:

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

Procedure

1. Start the httpd service and check the status:

   # systemctl start httpd
   # systemctl status httpd
   ...
   httpd[14523]: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:3131
   ...
   systemd[1]: Failed to start The Apache HTTP Server.
   ...

2. The SELinux policy assumes that httpd runs on port 80:

   # semanage port -l | grep http
   http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
   http_cache_port_t              udp      3130
   http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
   pegasus_http_port_t            tcp      5988
   pegasus_https_port_t           tcp      5989

3. Change the SELinux type of port 3131 to match port 80:

   # semanage port -a -t http_port_t -p tcp 3131

4. Start httpd again:

   # systemctl start httpd

5. However, the content remains inaccessible:

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 403 Forbidden
   ...

   Find the reason with the sealert tool:

   # sealert -l "*"
   ...
   SELinux is preventing httpd from getattr access on the file /var/test_www/html/index.html.
   ...

6. Compare SELinux types for the standard and the new path using the matchpathcon tool:

   # matchpathcon /var/www/html /var/test_www/html
   /var/www/html       system_u:object_r:httpd_sys_content_t:s0
   /var/test_www/html  system_u:object_r:var_t:s0

7. Change the SELinux type of the new /var/test_www/html/ content directory to the type of the default /var/www/html directory:

   # semanage fcontext -a -e /var/www /var/test_www

8. Relabel the /var directory recursively:

   # restorecon -Rv /var/
   ...
   Relabeled /var/test_www/html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
   Relabeled /var/test_www/html/index.html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

Verification

1. Check that the httpd service is running:

   # systemctl status httpd
   ...
   Active: active (running)
   ...
   systemd[1]: Started The Apache HTTP Server.
   httpd[14888]: Server configured, listening on: port 3131
   ...

2. Verify that the content provided by the Apache HTTP server is accessible:

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 200 OK
   Length: 0 [text/html]
   Saving to: ‘index.html’
   ...

Procedure

1. Identify SELinux booleans relevant for NFS, CIFS, and Apache:

   # semanage boolean -l | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs                 (off  ,  off)  Allow httpd to access cifs file systems
   httpd_use_nfs                  (off  ,  off)  Allow httpd to access nfs file systems

2. List the current state of the booleans:

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> off
   httpd_use_nfs --> off

3. Enable the identified booleans:

   # setsebool httpd_use_nfs on
   # setsebool httpd_use_cifs on

   Note

   Use setsebool with the -P option to make the changes persistent across restarts. A setsebool -P command requires a rebuild of the entire policy, and it might take some time depending on your configuration.

Verification

1. Check that the booleans are on:

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> on
   httpd_use_nfs --> on

Procedure

1. When your scenario is blocked by SELinux, the /var/log/audit/audit.log file is the first place to check for more information about a denial. To query Audit logs, use the ausearch tool. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as the Access Vector Cache (AVC), use the AVC and USER_AVC values for the message type parameter, for example:

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

   If there are no matches, check if the Audit daemon is running. If it does not, repeat the denied scenario after you start auditd and check the Audit log again.

2. In case auditd is running, but there are no matches in the output of ausearch, check messages provided by the systemd Journal:

   # journalctl -t setroubleshoot

3. If SELinux is active and the Audit daemon is not running on your system, then search for certain SELinux messages in the output of the dmesg command:

   # dmesg | grep -i -e type=1300 -e type=1400

4. Even after the previous three checks, it is still possible that you have not found anything. In this case, AVC denials can be silenced because of dontaudit rules.

   To temporarily disable dontaudit rules, allowing all denials to be logged:

   # semodule -DB

   After re-running your denied scenario and finding denial messages using the previous steps, the following command enables dontaudit rules in the policy again:

   # semodule -B

5. If you apply all four previous steps, and the problem still remains unidentified, consider if SELinux really blocks your scenario:

   • Switch to permissive mode:

     # setenforce 0
     $ getenforce
     Permissive

   • Repeat your scenario.

   If the problem still occurs, something different than SELinux is blocking your scenario.

Procedure

1. List more details about a logged denial using the sealert command, for example:

   $ sealert -l "*"
   SELinux is preventing /usr/bin/passwd from write access on the file
   /root/test.
   
   *****  Plugin leaks (86.2 confidence) suggests *****************************
   
   If you want to ignore passwd trying to write access the test file,
   because you believe it should not need this access.
   Then you should report this as a bug.
   You can generate a local policy module to dontaudit this access.
   Do
   # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd
   # semodule -X 300 -i my-passwd.pp
   
   *****  Plugin catchall (14.7 confidence) suggests **************************
   
   ...
   
   Raw Audit Messages
   type=AVC msg=audit(1553609555.619:127): avc:  denied  { write } for
   pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697
   scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
   tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
   
   ...
   
   Hash: passwd,passwd_t,admin_home_t,file,write

2. If the output obtained in the previous step does not contain clear suggestions:

   • Enable full-path auditing to see full paths to accessed objects and to make additional Linux Audit event fields visible:

     # auditctl -w /etc/shadow -p w -k shadow-write

   • Clear the setroubleshoot cache:

     # rm -f /var/lib/setroubleshoot/setroubleshoot.xml

   • Reproduce the problem.

   • Repeat step 1.

     After you finish the process, disable full-path auditing:

     # auditctl -W /etc/shadow -p w -k shadow-write

3. If sealert returns only catchall suggestions or suggests adding a new rule using the audit2allow tool, match your problem with examples listed and explained in SELinux denials in the Audit log.

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

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

   Note

   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:

   Note

   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.

Procedure

1. Create a new file named, for example, local_mcs_user.cil:

   # vim local_mcs_user.cil

2. Insert the following rule:

   (typeattributeset mcs_constrained_type (user_t))

3. Install the policy module:

   # semodule -i local_mcs_user.cil

Procedure

1. Modify existing categories or create new categories by editing the /etc/selinux/<selinuxpolicy>/setrans.conf file in a text editor. Replace <selinuxpolicy> with targeted or mls depending on the SELinux policy you use. For example:

   # vi /etc/selinux/targeted/setrans.conf

2. In the setrans.conf file for your policy, define the combinations of categories required by your scenario using the syntax s_<security level>_:c_<category number>_=<category.name>, for example:

   s0:c0=Marketing
   s0:c1=Finance
   s0:c2=Payroll
   s0:c3=Personnel

   • You can use category numbers from c0 to c1023.
   • In the targeted policy, use the s0 security level.
   • In the mls policy, you can label each combination of sensitivity levels and categories.
3. Optional: In the setrans.conf file, you can also label the MLS sensitivity levels.
4. Save and exit the file.

5. To make the changes effective, restart the MCS translation service:

   # systemctl restart mcstrans

Procedure

1. Define the security range for the SELinux user.

   # semanage user -m -rs0:c0,c1-s0:c0.c9 <user_u>

   Use category numbers c0 to c1023 or category labels as defined in the setrans.conf file. For additional information, see Defining category labels in MCS .

2. Assign MCS categories to a Linux user. You can specify only a range within the range defined to the relevant SELinux user:

   # semanage login -m -rs0:c1 <Linux.user1>

   Note

   You can add or remove categories from Linux users by using the chcat command. The following example adds <category1> and removes <category2> from <Linux.user1> and <Linux.user2>:

   # chcat -l -- +<category1>,-<category2> <Linux.user1>,<Linux.user2>

   Note that you must specify -- on the command line before using the -<category> syntax. Otherwise, the chcat command misinterprets the category removal as a command option.

Verification

1. Display the security context of the file to verify that it has the correct categories:

   $ ls -lZ <path/to/file>
   -rw-r--r--  <LinuxUser1> <Group1> root:object_r:user_home_t:_<sensitivity>_:_<category>_ <path/to/file>

   The specific security context of the file may differ.

2. Optional: Attempt to access the file when logged in as a Linux user not assigned to the same category as the file:

   $ cat <path/to/file>
   cat: <path/to/file>: Permission Denied

Procedure

1. For this example procedure, prepare a simple daemon that opens the /var/log/messages file for writing:

   1. Create a new file, and open it in a text editor of your choice:

      $ vi mydaemon.c

   2. Insert the following code:

      #include <unistd.h>
      #include <stdio.h>
      
      FILE *f;
      
      int main(void)
      {
      while(1) {
      f = fopen("/var/log/messages","w");
              sleep(5);
              fclose(f);
          }
      }

   3. Compile the file:

      $ gcc -o mydaemon mydaemon.c

   4. Create a systemd unit file for your daemon:

      $ vi mydaemon.service
      [Unit]
      Description=Simple testing daemon
      
      [Service]
      Type=simple
      ExecStart=/usr/local/bin/mydaemon
      
      [Install]
      WantedBy=multi-user.target

   5. Install and start the daemon:

      # cp mydaemon /usr/local/bin/
      # cp mydaemon.service /usr/lib/systemd/system
      # systemctl start mydaemon
      # systemctl status mydaemon
      ● mydaemon.service - Simple testing daemon
         Loaded: loaded (/usr/lib/systemd/system/mydaemon.service; disabled; vendor preset: disabled)
         Active: active (running) since Sat 2020-05-23 16:56:01 CEST; 19s ago
       Main PID: 4117 (mydaemon)
          Tasks: 1
         Memory: 148.0K
         CGroup: /system.slice/mydaemon.service
                 └─4117 /usr/local/bin/mydaemon
      
      May 23 16:56:01 localhost.localdomain systemd[1]: Started Simple testing daemon.

   6. Check that the new daemon is not confined by SELinux:

      $ ps -efZ | grep mydaemon
      system_u:system_r:unconfined_service_t:s0 root 4117    1  0 16:56 ?        00:00:00 /usr/local/bin/mydaemon

2. Generate a custom policy for the daemon:

   $ sepolicy generate --init /usr/local/bin/mydaemon
   Created the following files:
   /home/example.user/mysepol/mydaemon.te # Type Enforcement file
   /home/example.user/mysepol/mydaemon.if # Interface file
   /home/example.user/mysepol/mydaemon.fc # File Contexts file
   /home/example.user/mysepol/mydaemon_selinux.spec # Spec file
   /home/example.user/mysepol/mydaemon.sh # Setup Script

3. Rebuild the system policy with the new policy module using the setup script created by the previous command:

   # ./mydaemon.sh
   Building and Loading Policy
   + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
   Compiling targeted mydaemon module
   Creating targeted mydaemon.pp policy package
   rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
   + /usr/sbin/semodule -i mydaemon.pp
   ...

   Note that the setup script relabels the corresponding part of the file system using the restorecon command:

   restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system

4. Restart the daemon, and check that it now runs confined by SELinux:

   # systemctl restart mydaemon
   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

5. Because the daemon is now confined by SELinux, SELinux also prevents it from accessing /var/log/messages. Display the corresponding denial message:

   # ausearch -m AVC -ts recent
   ...
   type=AVC msg=audit(1590247112.719:5935): avc:  denied  { open } for  pid=8150 comm="mydaemon" path="/var/log/messages" dev="dm-0" ino=2430831 scontext=system_u:system_r:mydaemon_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file permissive=1
   ...

6. You can get additional information also using the sealert tool:

   $ sealert -l "*"
   SELinux is preventing mydaemon from open access on the file /var/log/messages.
   
    Plugin catchall (100. confidence) suggests *
   
   If you believe that mydaemon should be allowed open access on the messages file by default.
   Then you should report this as a bug.
   You can generate a local policy module to allow this access.
   Do
   allow this access for now by executing:
   # ausearch -c 'mydaemon' --raw | audit2allow -M my-mydaemon
   # semodule -X 300 -i my-mydaemon.pp
   
   Additional Information:
   Source Context                system_u:system_r:mydaemon_t:s0
   Target Context                unconfined_u:object_r:var_log_t:s0
   Target Objects                /var/log/messages [ file ]
   Source                        mydaemon
   
   ...

7. Use the audit2allow tool to suggest changes:

   $ ausearch -m AVC -ts recent | audit2allow -R
   
   require {
   	type mydaemon_t;
   }
   
   #============= mydaemon_t ==============
   logging_write_generic_logs(mydaemon_t)

8. Because rules suggested by audit2allow can be incorrect for certain cases, use only a part of its output to find the corresponding policy interface:

   $ grep -r "logging_write_generic_logs" /usr/share/selinux/devel/include/ | grep .if
   /usr/share/selinux/devel/include/system/logging.if:interface(`logging_write_generic_logs',`

9. Check the definition of the interface:

   $ cat /usr/share/selinux/devel/include/system/logging.if
   ...
   interface(`logging_write_generic_logs',`
           gen_require(`
                   type var_log_t;
           ')
   
           files_search_var($1)
           allow $1 var_log_t:dir list_dir_perms;
           write_files_pattern($1, var_log_t, var_log_t)
   ')
   ...

10. In this case, you can use the suggested interface. Add the corresponding rule to your type enforcement file:

    $ echo "logging_write_generic_logs(mydaemon_t)" >> mydaemon.te

    Alternatively, you can add this rule instead of using the interface:

    $ echo "allow mydaemon_t var_log_t:file { open write getattr };" >> mydaemon.te

11. Reinstall the policy:

    # ./mydaemon.sh
    Building and Loading Policy
    + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
    Compiling targeted mydaemon module
    Creating targeted mydaemon.pp policy package
    rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
    + /usr/sbin/semodule -i mydaemon.pp
    ...

Verification

1. Check that your application runs confined by SELinux, for example:

   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

2. Verify that your custom application does not cause any SELinux denials:

   # ausearch -m AVC -ts recent
   <no matches>

Procedure

1. Open a new .cil file with a text editor, for example:

   # vim <local_module>.cil

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

2. Insert the custom rules from a Known Issue or a Red Hat Solution.

   Important

   Do not write your own rules. Use only the rules provided in a specific Known Issue or Red Hat Solution.

   For example, to implement the SELinux denies cups-lpd read access to cups.sock in RHEL solution, insert the following rule:

   Note

   The example solution has been fixed permanently for RHEL in RHBA-2021:4420. Therefore, the parts of this procedure specific to this solution have no effect on updated RHEL 8 and 9 systems, and are included only as examples of syntax.

   (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read)))

   Note that you can use either of the two SELinux rule syntaxes, Common Intermediate Language (CIL) and m4. For example, (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read))) in CIL is equivalent to the following in m4:

   module local_cupslpd-read-cupssock 1.0;
   
   require {
       type cupsd_var_run_t;
       type cupsd_lpd_t;
       class sock_file read;
   }
   
   #============= cupsd_lpd_t ==============
   allow cupsd_lpd_t cupsd_var_run_t:sock_file read;

3. Save and close the file.

4. Install the policy module:

   # semodule -i <local_module>.cil

   Note

   When you want to remove a local policy module which you created by using semodule -i, refer to the module name without the .cil suffix. To remove a local policy module, use semodule -r <local_module>.

5. Restart any services related to the rules:

   # systemctl restart <service-name>

Verification

1. List the local modules installed in your SELinux policy:

   # semodule -lfull | grep "local_"
   400 local_module  cil

   Note

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

2. Search the SELinux policy for the relevant allow rules:

   # sesearch -A --source=<SOURCENAME> --target=<TARGETNAME> --class=<CLASSNAME> --perm=<P1>,<P2>

   Where <SOURCENAME> is the source SELinux type, <TARGETNAME> is the target SELinux type, <CLASSNAME> is the security class or object class name, and <P1> and <P2> are the specific permissions of the rule.

   For example, for the SELinux denies cups-lpd read access to cups.sock in RHEL solution:

   # sesearch -A --source=cupsd_lpd_t --target=cupsd_var_run_t --class=sock_file --perm=read
   allow cupsd_lpd_t cupsd_var_run_t:sock_file { append getattr open read write };

   The last line should now include the read operation.

3. Verify that the relevant service runs confined by SELinux:

   1. Identify the process related to the relevant service:

      $ systemctl status <service-name>

   2. Check the SELinux context of the process listed in the output of the previous command:

      $ ps -efZ | grep <process-name>

4. Verify that the service does not cause any SELinux denials:

   # ausearch -m AVC -ts recent
   <no matches>

1. Parsing the container spec file in the JSON format
2. Finding suitable allow rules based on the results of the first part
3. Generating final SELinux policy

Procedure

1. Install the udica package:

   # yum install -y udica

   Alternatively, install the container-tools module, which provides a set of container software packages, including udica:

   # yum module install -y container-tools

2. Start the ubi8 container that mounts the /home directory with read-only permissions and the /var/spool directory with permissions to read and write. The container exposes the port 21.

   # podman run --env container=podman -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

   Note that now the container runs with the container_t SELinux type. This type is a generic domain for all containers in the SELinux policy and it might be either too strict or too loose for your scenario.

3. Open a new terminal, and enter the podman ps command to obtain the ID of the container:

   # podman ps
   CONTAINER ID   IMAGE                                   COMMAND   CREATED          STATUS              PORTS   NAMES
   37a3635afb8f   registry.access.redhat.com/ubi8:latest  bash      15 minutes ago   Up 15 minutes ago           heuristic_lewin

4. Create a container JSON file, and use udica for creating a policy module based on the information in the JSON file:

   # podman inspect 37a3635afb8f > container.json
   # udica -j container.json my_container
   Policy my_container with container id 37a3635afb8f created!
   [...]

   Alternatively:

   # podman inspect 37a3635afb8f | udica my_container
   Policy my_container with container id 37a3635afb8f created!
   
   Please load these modules using:
   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}
   
   Restart the container with: "--security-opt label=type:my_container.process" parameter

5. As suggested by the output of udica in the previous step, load the policy module:

   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

6. Stop the container and start it again with the --security-opt label=type:my_container.process option:

   # podman stop 37a3635afb8f
   # podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

Verification

1. Check that the container runs with the my_container.process type:

   # ps -efZ | grep my_container.process
   unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 root 2275 434  1 13:49 pts/1 00:00:00 podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash
   system_u:system_r:my_container.process:s0:c270,c963 root 2317 2305  0 13:49 pts/0 00:00:00 bash

2. Verify that SELinux now allows access the /home and /var/spool mount points:

   [root@37a3635afb8f /]# cd /home
   [root@37a3635afb8f home]# ls
   username
   [root@37a3635afb8f ~]# cd /var/spool/
   [root@37a3635afb8f spool]# touch test
   [root@37a3635afb8f spool]#

3. Check that SELinux allows binding only to the port 21:

   [root@37a3635afb8f /]# yum install nmap-ncat
   [root@37a3635afb8f /]# nc -lvp 21
   ...
   Ncat: Listening on :::21
   Ncat: Listening on 0.0.0.0:21
   ^C
   [root@37a3635afb8f /]# nc -lvp 80
   ...
   Ncat: bind to :::80: Permission denied. QUITTING.

Procedure

1. Prepare your playbook. You can either start from the scratch or modify the example playbook installed as a part of the rhel-system-roles package:

   # cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml my-selinux-playbook.yml
   # vi my-selinux-playbook.yml

2. Change the content of the playbook to fit your scenario. For example, the following part ensures that the system installs and enables the selinux-local-1.pp SELinux module:

   selinux_modules:
   - { path: "selinux-local-1.pp", priority: "400" }

3. Save the changes, and exit the text editor.

4. Run your playbook on the host1, host2, and host3 systems:

   # ansible-playbook -i host1,host2,host3 my-selinux-playbook.yml

Procedure

1. Export your verified SELinux settings:

   # semanage export -f ./my-selinux-settings.mod

2. Copy the file with the settings to the new system:

   # scp ./my-selinux-settings.mod new-system-hostname:

3. Log in on the new system:

   $ ssh root@new-system-hostname

4. Import the settings on the new system:

   new-system-hostname# semanage import -f ./my-selinux-settings.mod