12.9. Managing the SELinux Policies for Subsystems

SELinux is a collection of mandatory access control rules which are enforced across a system to restrict unauthorized access and tampering. SELinux is described in more detail in the SELinux section in the Red Hat Enterprise Linux Deployment Guide.

12.9.1. About SELinux

Basically, SELinux identifies objects on a system, which can be files, directories, users, processes, sockets, or any other thing on a Linux host. These objects correspond to the Linux API objects. Each object is then mapped to a security context, which defines the type of object it is and how it is allowed to function on the Linux server.
System processes run within SELinux domains. Each domain has a set of rules that defines how the SELinux domain interacts with other SELinux objects on the system. This set of rules, then, determines which resources a process may access and what operations it may perform on those resources.
For Certificate System, each subsystem type runs within a specific domain for that subsystem type. Every instance of that subsystem type belongs to the same SELinux domain, regardless of how many instances are on the system For example, if there are three CAs installed on a server, all three belong to the pki_ca_t SELinux domain.
The rules and definitions for all the subsystems comprise the overall Certificate System SELinux policy. The SELinux policy is delivered in a separate RPM package (pki-selinux), which is installed as a prerequisite for the other Certificate System subsystem packages.
Certificate System SELinux policies are already configured when the subsystems are installed, and all SELinux policies are updated every time a subsystem is added with pkicreate or removed with pkiremove.

Example 12.7. Excerpts of the CA SELinux Policy

# types that the process runs as and the domain
type pki-ca_t, pki-ca_process;
type pki-ca_exec_t, pki-ca_executable;
init_daemon_domain(pki-ca_t, pki-ca_exec_t)

# types for config files
type pki-ca_etc_rw_t, pki-ca_config;

#types for the ports we need to use.
type pki-ca_port_t;

# This is for /etc/pki-ca/tomcat.conf:
can_exec(pki-ca_t, pki-ca_tomcat_exec_t)

The Certificate System subsystems run with SELinux set in enforcing mode, meaning that Certificate System operations can be successfully performed even when all SELinux rules are required to be followed.
By default, the Certificate System subsystems run confined by SELinux policies.

12.9.2. Viewing SELinux Policies for Subsystems

All Certificate System policies are installed with the pki-selinux package and are located in the /usr/share/selinux/modules/ directory, in the pki.pp file. The configured policies can be viewed using the SELinux Administration GUI.
  1. Open the Systems menu.
  2. Open the Administration menu, and select the SELinux Management item.
  3. To check the version of the Certificate System SELinux policy installed, click the Policy Module link.
  4. To view the policies set on the individual files and processes, click the File Labeling link. To view the policies for the port assignments for the subsystems, click the Network Port link.

12.9.3. Relabeling Subsystem and LDAP Ports

When a subsystem instance is created, pkicreate automatically creates all of the required SELinux labels for the ports used by the instance. There can be times when the SELinux labels for ports needs to be managed manually, however. For example, if a Certificate System instance changes its port assignments (Section 12.5.2, “Changing a Port Number”), then the SELinux labels need to be updated.
Likewise, the Certificate System SELinux policies make certain assumptions about the configuration of the LDAP server used by the instances, and if the Directory Server instance uses non-standard ports, then these ports must be labeled in the Certificate System SELinux policies, or PKI operations may fail. The default LDAP and LDAPS ports, 389 and 636, respectively, are already labeled as part of the policies in Red Hat Enterprise Linux. To use nonstandard LDAP ports for the Certificate System internal database, then the proper SELinux labels must be made to use those ports. That can be done in the SELinux administrative interface shown in Section 12.9.2, “Viewing SELinux Policies for Subsystems” or using the semanage script.
Use the port subcommand, the -t option to identify the security context, and the -p option to identify the port. The -a option adds the port label. For example:
/usr/sbin/semanage port -a -t ldap_port_t -p tcp 1636
To delete a port label, use the -d option. For example:
/usr/sbin/semanage port -d -t ldap_port_t -p tcp 1636

12.9.4. Relabeling nCipher netHSM Contexts

The nCipher netHSM software does not come with its own SELinux policy, so the Certificate System contains a default netHSM policy, shown in Example 12.8, “netHSM SELinux Policy”.

Example 12.8. netHSM SELinux Policy

# default labeling for nCipher
/opt/nfast/scripts/init.d/(.*)  gen_context(system_u:object_r:initrc_exec_t,s0)
/opt/nfast/sbin/init.d-ncipher  gen_context(system_u:object_r:initrc_exec_t,s0)
/opt/nfast(/.*)?                gen_context(system_u:object_r:pki_common_t, s0)
/dev/nfast(/.*)?                gen_context(system_u:object_r:pki_common_dev_t,0)

Other rules allow the pki_*_t domain to talk to files that are labeled pki_common_t and pki_common_dev_t.
If any of the nCipher configuration is changed (even if it is in the default directory, /opt/nfast), run the restorecon to make sure all files are properly labeled:
restorecon -R /dev/nfast
restorecon -R /opt/nfast
If the nCipher software is installed in a different location or if a different HSM is used, the default Certificate System HSM policy needs to be relabelled using semanage.