Overview of configuration options

Configuration options include top-level options, benchmark options, and Center for Internet Security (CIS)-specific options.

Find and set configuration options

You can find the configuration options for a specific control in the Reference: Benchmarks and controls. The reference is divided into sections, with each section representing a CIS Benchmark or a DISA STIG standard. Each CIS benchmark has a list of associated controls, and additional information is provided for each control:
  • Parameters: Configuration options for a control, along with the data type and default value.
  • Supported Levels: The supported levels for a CIS control.
  • Supported Profiles: The supported profiles for a CIS control.
  • Hiera Configuration Example: Snippet of Hiera that can be used to configure a control.
  • Alternate Config IDs: The alternate config IDs for a control. Any of these config IDs, along with the full control name, can be used as a key in the control_config hash.
  • Resource: The name of the Puppet resource that enforces the control.

Each DISA STIG standard has a similar list of controls. Detailed information is provided about each DISA STIG control; however, alternate config IDs are not listed because they are not applicable.

Guidelines for specifying config IDs

You can specify CIS controls in the control_config hash by referencing the full control name, the control number, the normalized control name, or the normalized control number. You cannot mix and match these forms and must pick a single config ID form to use for your config. Full control names and control numbers are copied verbatim from the benchmarks and are case-sensitive. Normalized control names have lowercase letters and contain only alphanumeric characters and underscores. Normalized control numbers are always prefixed with a c and contain only numeric characters separated by underscores.

Example of alternate config IDs:
  • Full control name: (L1) Ensure 'Enforce password history' is set to '24 or more password(s)'
  • Control number: 1.1.1
  • Normalized control name: ensure_enforce_password_history_is_set_to_24_or_more_passwords
  • Normalized number: c1_1_1

Top-level configuration options

In the Hiera tool, the top-level configuration options are found directly under the cem_linux namespace. If you must customize CEM to meet your organization's requirements, you can specify values for the top-level configuration options.

In Hiera, the top-level options are prefixed with cem_linux:. The following list describes the options:
  • benchmark - Enum['cis','stig'] - the compliance framework to use. CEM for Linux supports only cis and stig. Default: cis.
  • config - Optional[Hash] - the location for all non-top-level configuration options. Default: undef.
  • allow_on_kubernetes_node - Boolean - If cem_linux detects that it is running on a Kubernetes cluster node or host, CEM does not enforce controls, and it logs a warning. In this way, CEM helps to prevent the accidental enforcement of incorrect compliance settings that can render Kubernetes non-functional. Default: false.
  • manage_gnome - Boolean - When set to true, controls are enforced to secure a GNOME desktop environment. When set to false, the controls are not enforced. Default: false.
  • disable_package_gpgcheckBoolean – When set to true, GNU Privacy Guard (GPG) checks of downloaded packages are disabled. Disabling GPG checks can be helpful in rare cases if you enable more stringent system encryption standards, such as the Federal Information Processing Standards (FIPS). These tighter standards can introduce stricter criteria than are normally applied to GPG package signatures. If GPG and more stringent criteria are applied simultaneously, package downloads can fail. Specify disable_package_gpgcheck=true only when necessary because this setting can make your infrastructure less secure. Default: false.
  • regenerate_grub2_config - Boolean - Some configurations in CEM for Linux modify the Grub2 bootloader configuration. To regenerate the Grub2 configuration after applying a change, set this parameter to true. If you do not set this parameter to true, you must manually regenerate the Grub2 configuration. Default: false.
  • set_grub2_password - Boolean - Set the password for the Grub2 bootloader. If you set this value to true, you must also set the grub2_superuser and grub2_superuser_password parameters, or configure the specific bootloader password control by using the control_configs option. Default: false.
  • grub2_superuser - Optional[String[1]] - The superuser for the Grub2 bootloader if you set the set_grub2_password parameter to true. Default: Undef.
  • grub2_superuser_password - Optional[Sensitive[String]] - The superuser password for the Grub2 bootloader if you set the set_grub2_password parameter to true. This value is sensitive in terms of security, and should be stored in a Sensitive data type. Default: Undef.

Hiera example

The following example configures CEM for Linux to regenerate the Grub2 bootloader config on a node using the CIS benchmark:
cem_linux::benchmark: 'cis'
cem_linux::allow_on_kubernetes_node: false
cem_linux::regenerate_grub2_config: true
cem_linux::config:
  ...

Benchmark configuration options

Each Center for Internet Security (CIS) Benchmark is associated with a set of configuration options. You can use the Hiera tool to specify values for the benchmark configuration options.

The benchmark configuration options are available as key-value pairs within the cem_linux::config: hash. The following options are available:
  • only: - Optional[Array[String]] — takes an array of control class names (manifests/benchmarks/<benchmark>/controls/*.pp). Classes specified here are included in the catalog. This option takes precedence over ignore:. Default: undef.
  • ignore: - Optional[Array[String]] — takes an array of control class names (manifests/benchmarks/<benchmark>/controls/*.pp). The classes specified here are not included in the catalog. If only: is specified, this option does nothing. Default: undef.
  • control_configs - Optional[Hash] — where all rule-specific configurations live. Default: undef.

CIS-specific configuration options

To meet your organization's requirements, you can specify CIS-specific configuration options, such as settings related to firewalls and log files. Use the Hiera tool to specify these options.

The CIS-specific configuration options are available as key-value pairs within the cem_linux::config: hash:
  • profile: - Optional[Enum['server', 'workstation']] — the name of the benchmark profile. The only value supported by CEM is server. Default: server.
  • level: - Optional[Enum['1', '2']] — the name of the profile level. Default: 1.
  • firewall_type: - Optional[Enum['iptables', 'firewalld', 'unmanaged']] — the preferred firewall provider. If set to unmanaged, CEM will not enforce firewall-related rules. Default: firewalld.
  • enable_systemd_journal - Optional[Boolean] - Whether to enable the systemd-journal logging service. The default value is false. If this option is enabled, the systemd-journal-remote package will be installed and the systemd-journal-upload.service service will be enabled. However, several configuration parameters are required to ensure that the systemd-journal-upload.service functions correctly:
    cem_linux::config:
      control_configs:
        'ensure_systemd_journal_remote_is_configured':
          address: '<IP address or FQDN of the remote host>'
          server_key_file: '<path to the server key file>'
          server_certificate_file: '<path to the server certificate file>'
          trusted_certificate_file: '<path to the trusted certificate file>'

Options specific to Red Hat Enterprise Linux 8

The authselect utility can be used to configure user authentication on a Red Hat Enterprise Linux (RHEL) host. If you installed CEM on a RHEL 8 operating system, authselect options are available, but should be avoided in almost all cases. The authselect utility is disabled by default because enablement of authselect can break authentication methods, and use of the utility requires extensive configuration.

Authselect options

The following authselect options are available for RHEL 8:
  • use_authselect: - Optional[Boolean] - Whether to use authselect to manage most authentication options. Defaults to false.
  • authselect_profile - Optional[String] - Profile for authselect configuration options. If using the authselect utility, you must specify an authselect profile. Defaults to undef.

Restrictions

CAUTION:
  • If a node is joined to an Active Directory domain or to Red Hat Identity Management (idM), do not enable the authselect utility. Enabling the authselect utility on these nodes will break your authentication configurations.
  • You cannot enable the authselect option if you are using pluggable authentication modules (PAMs) for application management.

Enabling the authselect utility

Both of the authselect options must be set directly in the cem_linux::config hash for the authselect utility to work properly. All authselect configurations are managed via the ensure_custom_authselect_profile_is_used control, regardless of whether you use a custom profile.

To enable the authselect utility:
  1. Set the config option use_authselect to true.
  2. Specify an authselect profile with the config option authselect_profile.

By default, cem_linux uses standard PAM rules to configure the authentication controls specified by CIS. However, if you are enforcing CIS compliance on RHEL 8, CIS guidelines call for the authselect utility to be used. The following configuration example shows how to enable the authselect utility on a node by using the minimal system default profile:

# control-repo/data/nodes/<node name>.yaml
---
cem_linux::config:
  use_authselect: true
  authselect_profile: 'minimal'

Custom authselect profiles

If you are enforcing CIS compliance on a RHEL 8 system and you want to enable additional features for your authselect profile, you can create a custom profile.

To create a custom authselect profile in cem_linux, prefix the profile name in authselect_profile with custom/. If the custom profile does not exist on the node, the profile will be created automatically. The following example shows how to create and use a custom profile, my_custom_profile, which is based on the minimal system profile with additional features enabled:

# control-repo/data/nodes/<node name>.yaml
---
cem_linux::config:
  use_authselect: true
  authselect_profile: 'custom/my_custom_profile'
  control_configs:
    ensure_custom_authselect_profile_is_used:
      custom_profile_base: 'minimal'
      profile_features:
        - with-faillock
        - with-mkhomedir

For more information about authselect features, see the authselect documentation in the Red Hat Customer Portal.