SELinux is installed by default when installing SLE Micro by YaST or is part of the pre-built images. The default mode is set to permissive on all deployment types, and the file system is labelled.

To set the SELinux mode to enforcing and configure your system properly for using SELinux, run the following command:

# transactional-update setup-selinux

Reboot your system after the command has finished. The command installs the SELinux policy if it is not installed, sets the enforcing SELinux mode and rebuilds initrd.

SELinux can run in one of three modes: disabled, permissive, or enforcing.

Using the disabled mode means that no rules from the SELinux policy are applied and your system is not protected. Therefore, the disabled mode is not recommended.

In the permissive mode, SELinux is active, the security policy is loaded, the file system is labeled and access denial entries are logged. However, the policy is not enforced and thus no access is actually denied.

In the enforced mode, the security policy is applied. Each access that is not explicitly allowed by the policy is denied.

You can switch between the enforcing and permissive modes by using the setenforce command. Alternatively, you can switch between all SELinux modes by editing the /etc/selinux/config configuration file. Changes performed by the setenforce command are valid only until the next reboot. For persistent changes of the SELinux mode, edit the /etc/selinux/config configuration file.

The setenforce command has the following syntax:

# setenforce MODE_ID

where MODE_ID is 0 for the permissive mode or 1 for the enforced mode.

To verify the mode, run the following command:

# getenforce

The command should return permissive or enforced, depending on the provided MODE_ID.

To change the SELinux mode permanently, in the file /etc/selinux/config, change the value of SELINUX to disabled, or permissive, or enforced as follows:

SELINUX=disabled

The changes in the file are applied after the next reboot.

Note: Relabeling your system after switching from the disabled mode

If you disable SELinux on your system and then enable it later, make sure that you relabel your system. When SELinux is disabled, and you perform changes to your file system, the changes are not reflected in the context anymore (for example, new files do not have any context). Therefore, you need to relabel your system by using the restorecon command, using the autorelabel boot parameter, or by creating a file that will trigger relabeling on the next boot. To create the file, run the following command:

# touch /etc/selinux/.autorelabel

After reboot, the file /etc/selinux/.autorelabel is replaced with another flag file: /etc/selinux/.relabelled to prevent relabeling on subsequent reboots.

The policy is the key component in SELinux. Your SELinux policy defines rules that specify which objects can access which files, directories, ports, and processes on a system. To do this, a security context is defined for all of these.

An SELinux policy contains a huge number of rules. To make it more manageable, policies are often split into modules. This allows the administrator to switch protection on or off for different parts of the system.

When compiling the policy for your system, you will have a choice to either work with a modular policy, or a monolithic policy, where one huge policy is used to protect everything on your system. It is strongly recommended to use a modular policy and not a monolithic policy. Modular policies are much easier to manage.

SLE Micro is shipped with the targeted SELinux policy.

The security context is a set of information assigned to a file or a process. It consists of SELinux user, role, type, level and category. This information is used to make access control decisions.

SLE Micro provides you with tools to manage SELinux on your system. If, in any case, the below described tools are not installed on your system, install the tools by running:

# transactional-update pkg install policycoreutils-python-utils

After successful installation, reboot the system.

Note: The Z option available to other commands

You can also use the Z option with other commands, for example: cp, ps, and id.

Keylime is a remote attestation solution that enables you to monitor the health of remote nodes using a TPM as a root of trust for measurement. With Keylime, you can perform several tasks like validation of the PCRs extended during the measured boot, analysis and assertions of the event log, assertion of the value of any PCR in the remote system, and also monitoring the validity of open or executed files.

Keylime also provides a framework for delivering encrypted data to verified nodes. This data is the so-called payload. The framework can also execute custom scripts that are triggered when a machine fails the attested measurements.

Keylime also provides a framework for delivering encrypted data to verified nodes. This data is the so-called payload. The framework can also execute custom scripts that are triggered when a machine fails the attested measurements.

Keylime consists of an agent, a verifier, a registrar, and a command-line tool (tenant). Agents are on those systems that need to be attested. The verifier and registrar are on remote systems that perform the registration and attestation of agents. Keep in mind that only the agent role is available on SLE Micro. For details about each component, refer to the following sections.

Before you start installing and registering agents, prepare the verifier and the registrar on remote hosts as described in the following procedure.

The Keylime agent is not present on SLE Micro by default, you need to install it manually. To install the agent, proceed as follows:

Note: SLE Micro does not provide the tenant, registrar or verifier

SLE Micro provides only the Keylime agent capability, therefore, the tasks performed in this chapter cannot be performed from your SLE Micro.

You can register a new agent either by using the CLI tenant or by editing the configuration of the verifier. Using the tenant on the verifier host, run the following:

# keylime_tenant -v 127.0.0.1 \
                -t AGENT \
                -u UUID \
                --cert default \
                -c add
                [--include PATH_TO_ZIP_FILE]

Where:

You can list registered agents by using the reglist command on the verifier host as follows:

# keylime_tenant -v 127.0.0.1 \
                --cert default \
                -c reglist

To remove a registered agent, specify the agent using the -t and -u options and the -c delete command as follows:

# keylime_tenant -v 127.0.0.1 \
              -t AGENT \
              -u UUID \
              -c delete

A secure payload enables you to deliver encrypted data to healthy agents. Typically, these payloads are used to provide keys, passwords, certificates, configurations, or scripts that are further used by the agent.

The secure payload is delivered to the agent in a zip file that must contain a shell script—autorun.sh. The script will be executed only if the agent has been properly registered and verified. To deliver the zip file, use the --include option of the keylime_tenant command.

The script autorun.sh contains steps that will enable the use of passwords, certificates and so on. For example, the script can create a directory structure and copy SSH keys there:

#!/bin/bash
 
 mkdir -p /root/.ssh/
 cp id_rsa* /root/.ssh/
 chmod 600 /root/.ssh/id_rsa*
 cp /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys

In this case, do not forget to include the SSH keys in the zip file.

When using IMA, the kernel calculates a hash of accessed files. The hash is then used to extend the PCR 10 in the TPM and also log a list of accessed files. The verifier can request a signed quote to the agent for PCR 10 to get the logs of all accessed files including the file hashes. Verifiers then compare the accessed files with a local allowlist of approved files. If any of the hashes are not recognized, the system is considered unsafe, and a revocation event is triggered.

For a high-level overview of IMA/EVM, refer to IMA/EVM introduction.

Before Keylime can collect information, IMA/EVM needs to be enabled. To enable the process, boot a kernel of the agent with the parameters: ima_appraise=log and ima_policy=tcb. To use the boot parameters on boot, proceed as follows:

The procedure above uses the default kernel IMA policy, but we recommend creating a new policy to avoid monitoring too many files and therefore creating long logs. For details, refer to the Keylime documentation.

To indicate the expected hashes, use the --allowlistoption of the keylime_tenant command when registering the agent. To view the excluded or ignored files, use the --exclude option of the keylime_tenant command:

# keylime_tenant --allowlist
    -v 127.0.0.1 \
    -u UUID

System administrators and programmers often want to restrict access to certain parts of the system or to limit the use of certain functions of an application. Without PAM, applications must be adapted every time a new authentication mechanism, such as LDAP, Samba, or Kerberos, is introduced. However, this process is time-consuming and error-prone. One way to avoid these drawbacks is to separate applications from the authentication mechanism and delegate authentication to centrally managed modules. Whenever a newly required authentication scheme is needed, it is sufficient to adapt or write a suitable PAM module for use by the program in question.

The PAM concept consists of:

PAM on SLE Micro comes with a set of configuration files stored in /etc/pam.d. Every service (or program) that relies on the PAM mechanism has its own configuration file in this directory. For example, the service for sshd can be found in the /etc/pam.d/sshd file.

The files under /etc/pam.d/ define the PAM modules used for authentication. Each file consists of lines, which define a service, and each line consists of a maximum of four components:

TYPE  CONTROL
 MODULE_PATH  MODULE_ARGS

The components have the following meaning:

In addition, there are global configuration files for PAM modules under /etc/security, which define the exact behavior of these modules (examples include pam_env.conf and time.conf). Every application that uses a PAM module actually calls a set of PAM functions, which then process the information in the various configuration files and return the result to the requesting application.

To simplify the creation and maintenance of PAM modules, common default configuration files for the types auth, account, password, and session modules have been introduced. These are retrieved from every application's PAM configuration. Updates to the global PAM configuration modules in common-* are thus propagated across all PAM configuration files without requiring the administrator to update every single PAM configuration file.

The global PAM configuration files are maintained using the pam-config tool. This tool automatically adds new modules to the configuration, changes the configuration of existing ones or deletes modules (or options) from the configurations. Manual intervention in maintaining PAM configurations is minimized or no longer required.

Consider the PAM configuration of sshd as an example:

#%PAM-1.0 1
auth     requisite      pam_nologin.so                              2
auth     include        common-auth                                 3
account  requisite      pam_nologin.so                              2
account  include        common-account                              3
password include        common-password                             3
session  required       pam_loginuid.so                             4
session  include        common-session                              3
session  optional       pam_lastlog.so   silent noupdate showfailed 5

By including the configuration files instead of adding each module separately to the respective PAM configuration, you automatically get an updated PAM configuration when an administrator changes the defaults. Formerly, you needed to adjust all configuration files manually for all applications when changes to PAM occurred or a new application was installed. Now the PAM configuration is made with central configuration files and all changes are automatically inherited by the PAM configuration of each service.

The first include file (common-auth) calls three modules of the auth type: pam_env.so, pam_gnome_keyring.so and pam_unix.so. See Example 3.2, “Default configuration for the auth section (common-auth)”.

auth  required  pam_env.so                   1
auth  optional  pam_gnome_keyring.so         2
auth  required  pam_unix.so  try_first_pass 3

The whole stack of auth modules is processed before sshd gets any feedback about whether the login has succeeded. All modules of the stack having the required control flag must be processed successfully before sshd receives a message about the positive result. If one of the modules is not successful, the entire module stack is still processed and only then is sshd notified about the negative result.

When all modules of the auth type have been successfully processed, another include statement is processed, in this case, that in Example 3.3, “Default configuration for the account section (common-account)”. common-account contains only one module, pam_unix. If pam_unix returns the result that the user exists, sshd receives a message announcing this success and the next stack of modules (password) is processed, shown in Example 3.4, “Default configuration for the password section (common-password)”.

account  required  pam_unix.so  try_first_pass

password  requisite  pam_cracklib.so
password  requisite   pam_cracklib.so  
password  required   pam_unix.so  use_authtok nullok shadow try_first_pass

Again, the PAM configuration of sshd involves only an include statement referring to the default configuration for password modules located in common-password. These modules must successfully be completed (control flags requisite and required) whenever the application requests the change of an authentication token.

Changing a password or another authentication token requires a security check. This is achieved with the pam_cracklib module. The pam_unix module used afterward carries over any old and new passwords from pam_cracklib, so the user does not need to authenticate again after changing the password. This procedure makes it impossible to circumvent the checks carried out by pam_cracklib. Whenever the account or the auth type are configured to complain about expired passwords, the password modules should also be used.

session  required  pam_selinux.so  close
session  optional  pam_systemd.so
session  required  pam_limits.so
session  required  pam_unix.so  try_first_pass
session  optional  pam_umask.so
session  required  pam_selinux.so  open
session  optional  pam_env.so

As the final step, the modules of the session type (bundled in the common-session file) are called to configure the session according to the settings for the user in question. The pam_limits module loads the file /etc/security/limits.conf, which may define limits on the use of certain system resources. The pam_unix module is processed again. The pam_umask module can be used to set the file mode creation mask. Since this module carries the optional flag, a failure of this module would not affect the successful completion of the entire session module stack. The session modules are called a second time when the user logs out.

Some PAM modules are configurable. The configuration files are located in /etc/security. This section briefly describes the configuration files relevant to the sshd example—pam_env.conf and limits.conf.

VARIABLE  [DEFAULT=VALUE]  [OVERRIDE=VALUE]

REMOTEHOST  DEFAULT=localhost          OVERRIDE=@{PAM_RHOST}
DISPLAY     DEFAULT=${REMOTEHOST}:0.0  OVERRIDE=${DISPLAY}

The pam-config tool helps you configure the global PAM configuration files (/etc/pam.d/common-*) and several selected application configurations. For a list of supported modules, use the pam-config --list-modules command. Use the pam-config command to maintain your PAM configuration files. Add new modules to your PAM configurations, delete other modules or modify options to these modules. When changing global PAM configuration files, no manual tweaking of the PAM setup for individual applications is required.

A simple use case for pam-config involves the following:

For more information on the pam-config command and the options available, refer to the manual page of pam-config(8).

If you prefer to manually create or maintain your PAM configuration files, make sure to disable pam-config for these files.

When you create your PAM configuration files from scratch using the pam-config --create command, it creates symbolic links from the common-* to the common-*-pc files. pam-config only modifies the common-*-pc configuration files. Removing these symbolic links effectively disables pam-config, because pam-config only operates on the common-*-pc files and these files are not put into effect without the symbolic links.

Warning: Include pam_systemd.so in configuration

If you are creating your own PAM configuration, make sure to include pam_systemd.so configured as session optional. Not including the pam_systemd.so can cause problems with systemd task limits. For details, refer to the man page of pam_systemd.so.

To provide more security during the local login , you can configure two-factor authentication using the pam-u2f framework and the U2F feature on Yubikeys and Security Keys.

To set up U2F on your system, you need to associate your key with your account . After that, configure your system to use the key. The procedure is described in the following sections.

3.7.1 Associating the U2F key with your account #

  

To associate your U2F key with your account proceed as follows:

1. Log in to your machine.

2. Insert your U2F key.

3. Create a directory for the U2F key configuration:

   > sudo mkdir -p ~/.config/Yubico

4. Run the pamu2fcfg that outputs configuration lines:

   > sudo pamu2fcfg > ~/.config/Yubico/u2f_keys

5. When your device begins flashing, touch the metal contact to confirm the association.

We recommend using a backup U2F device, which you can set up by running the following commands:

1. Run:

   > sudo pamu2fcfg -n >> ~/.config/Yubico/u2f_keys

2. When your device begins flashing, touch the metal contact to confirm the association.

You can move the output file from the default location to a directory that requires the sudo permission to modify the file to increase security, for example, to the /etc directory. To do so, follow the steps:

1. Create a directory in /etc:

   > sudo mkdir /etc/Yubico

2. Move the created file:

   > sudo mv ~/.config/Yubico/u2f_keys /etc/Yubico/u2f_keys

Note: Placing the u2f_keys to a non-default location

If you move the output file to a different directory than is the default ($HOME/.config/Yubico/u2f_keys), you need to add the path to the /etc/pam.d/login file as described in Section 3.7.2, “Updating the PAM configuration”.

Every vendor that develops and maintains cryptographic applications and wants them to be tested for FIPS compliance must submit them to the Cryptographic Module Validation Program (CMVP) (see https://csrc.nist.gov/projects/cryptographic-module-validation-program).

The latest FIPS 140-3 standard was approved in March 2019 and replaces 140-2.

Warning: FIPS requires expertise

Administering FIPS is complex and requires significant expertise. Implementing it correctly, testing and troubleshooting all require a high degree of knowledge.

Only run your SLE Micro in FIPS mode when it is required to meet compliance rules. Otherwise, we do not recommend running your systems in FIPS mode.

Below are some reasons to not use FIPS mode (if not required explicitly):

To install the FIPS pattern on a running system, proceed as follows:

Alternatively, you can install the pattern during the manual installation under Software as described in Book “Deployment Guide”, Chapter 12 “Installation steps”, Section 12.9 “Installation Settings”. Then adjust the boot loader configuration as described in the procedure above.

Important: Undergoing FIPS 140-3 certification

The relevant binaries are currently undergoing FIPS 140-3 certification. Until the certification has been achieved, full FIPS 140-3 compliance cannot be guaranteed

Note: Installing and enabling FIPS on a running system

If you install and enable the FIPS mode on a running system, you might need to make adjustments, such as regenerating keys and auditing your setup to ensure it is set up correctly.

If you run SLE Micro in the FIPS mode and you use only the SLE 15 SP4 BCI-based containers, then such a setup can serve as a FIPS-compliant platform. If you intend to run a third party container on SLE Micro, check the container's FIPS compatibility before deploying it.

According to the FIPS standards, MD5 is not a secure hashing algorithm, and it must not be used for authentication. If you run a FIPS-compliant network environment, and you have clients or servers that run in FIPS-compliant mode, you must use a Kerberos service for authenticating Samba/CIFS users. This is necessary as all other Samba authentication modes include MD5.

For more information, refer to: