Security hardening

Procedure

1. Add the fips=1 option to the kernel command line during the system installation.
2. During the software selection stage, do not install any third-party software.
3. After the installation, the system starts in FIPS mode automatically.

Procedure

1. Create a plain text file in the Tom’s Obvious, Minimal Language (TOML) format with the following content:

   name = "system-fips-mode-enabled"
   description = "blueprint with FIPS enabled "
   version = "0.0.1"
   
   [customizations]
   fips = true
   
   [[customizations.user]]
   name = "admin"
   password = "admin"
   groups = ["users", "wheel"]

2. Import the blueprint to the RHEL image builder server:

   # composer-cli blueprints push <blueprint-name>.toml

3. List the existing blueprints to check whether the created blueprint is successfully imported and exists:

   # composer-cli blueprints show <blueprint-name>

4. Check whether the components and versions listed in the blueprint and their dependencies are valid:

   # composer-cli blueprints depsolve <blueprint-name>

5. Build the customized RHEL image:

   # composer-cli compose start \ <blueprint-name> \ <image-type> \

6. Review the image status:

   # composer-cli compose status
   …
   $ <UUID> FINISHED <date> <blueprint-name> <blueprint-version> <image-type>
   …

7. Download the image:

   # composer-cli compose image <UUID>

   RHEL image builder downloads the image to the current directory path. The UUID number and the image size are displayed alongside:

   $ <UUID-image-name.type>: <size> MB

Verification

1. Log in to the system image with the username and password that you configured in your blueprint.

2. Check if FIPS mode is enabled:

   $ cat /proc/sys/crypto/fips_enabled
   1

Procedure

1. Create a Containerfile with the following instructions to enable the fips=1 kernel argument:

   FROM registry.redhat.io/rhel9/rhel-bootc:latest
   # Enable fips=1 kernel argument: https://containers.github.io/bootc/building/kernel-arguments.html
   COPY 01-fips.toml /usr/lib/bootc/kargs.d/
   # Enable the FIPS crypto policy
   # crypto-policies-scripts is not installed by default in RHEL-10
   RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS

2. Create your bootc-compatible base disk images with bootc-image-builder.

Procedure

1. Optional: Display the current cryptographic policy:

   $ update-crypto-policies --show
   DEFAULT

2. Set the new cryptographic policy:

   # update-crypto-policies --set <POLICY>
   <POLICY>

   Replace <POLICY> with the policy or subpolicy you want to set, for example FUTURE, LEGACY or FIPS:OSPP.

3. Restart the system:

   # reboot

Procedure

1. To switch the system-wide cryptographic policy to the LEGACY level, enter the following command as root:

   # update-crypto-policies --set LEGACY
   Setting system policy to LEGACY

Procedure

1. Apply the SHA1 subpolicy to the DEFAULT cryptographic policy:

   # update-crypto-policies --set DEFAULT:SHA1
   Setting system policy to DEFAULT:SHA1
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.

2. Restart the system:

   # reboot

Procedure

1. Log in to the RHEL 10 web console.

   For details, see Logging in to the web console.

2. In the Configuration card of the Overview page, click your current policy value next to Crypto policy.

   

3. In the Change crypto policy dialog window, click on the policy you want to start using on your system.

   

4. Click the Apply and reboot button.

Procedure

1. Checkout to the /etc/crypto-policies/policies/modules/ directory:

   # cd /etc/crypto-policies/policies/modules/

2. Create subpolicies for your adjustments, for example:

   # touch MYCRYPTO-1.pmod
   # touch SCOPES-AND-WILDCARDS.pmod

   Important

   Use upper-case letters in file names of policy modules.

3. Open the policy modules in a text editor of your choice and insert options that modify the system-wide cryptographic policy, for example:

   # vi MYCRYPTO-1.pmod

   min_rsa_size = 3072
   hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512

   # vi SCOPES-AND-WILDCARDS.pmod

   # Disable the AES-128 cipher, all modes
   cipher = -AES-128-*
   
   # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
   cipher@TLS = -CHACHA20-POLY1305
   
   # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
   group@SSH = FFDHE-1024+
   
   # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
   cipher@SSH = -*-CBC
   
   # Allow the AES-256-CBC cipher in applications using libssh
   cipher@libssh = AES-256-CBC+

4. Save the changes in the module files.

5. Apply your policy adjustments to the DEFAULT system-wide cryptographic policy level:

   # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS

6. To make your cryptographic settings effective for already running services and applications, restart the system:

   # reboot

Procedure

1. Create a policy file for your customizations:

   # cd /etc/crypto-policies/policies/
   # touch MYPOLICY.pol

   Alternatively, start by copying one of the four predefined policy levels:

   # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

2. Edit the file with your custom cryptographic policy in a text editor of your choice to fit your requirements, for example:

   # vi /etc/crypto-policies/policies/MYPOLICY.pol

3. Switch the system-wide cryptographic policy to your custom level:

   # update-crypto-policies --set MYPOLICY

4. To make your cryptographic settings effective for already running services and applications, restart the system:

   # reboot

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure cryptographic policies
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the FUTURE cryptographic security policy on the managed node
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
         vars:
           - crypto_policies_policy: FUTURE
           - crypto_policies_reboot_ok: true

   The settings specified in the example playbook include the following:

   crypto_policies_policy: FUTURE

   Configures the required cryptographic policy (FUTURE) on the managed node. It can be either the base policy or a base policy with some sub-policies. The specified base policy and sub-policies have to be available on the managed node. The default value is null. It means that the configuration is not changed and the crypto_policies RHEL system role will only collect the Ansible facts.

   crypto_policies_reboot_ok: true

   Causes the system to reboot after the cryptographic policy change to make sure all of the services and applications will read the new configuration files. The default value is false.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the control node, create another playbook named, for example, verify_playbook.yml:

   ---
   - name: Verification
     hosts: managed-node-01.example.com
     tasks:
       - name: Verify active cryptographic policy
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
       - name: Display the currently active cryptographic policy
         ansible.builtin.debug:
           var: crypto_policies_active

   The settings specified in the example playbook include the following:

   crypto_policies_active

   An exported Ansible fact that contains the currently active policy name in the format as accepted by the crypto_policies_policy variable.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/verify_playbook.yml

3. Run the playbook:

   $ ansible-playbook ~/verify_playbook.yml
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   The crypto_policies_active variable shows the active policy on the managed node.

Procedure

1. List all keys provided by the OpenSC PKCS #11 module including their PKCS #11 URIs and save the output to the keys.pub file:

   $ ssh-keygen -D pkcs11: > keys.pub

2. Transfer the public key to the remote server. Use the ssh-copy-id command with the keys.pub file created in the previous step:

   $ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>

3. Connect to <ssh-server-example.com> by using the ECDSA key. You can use just a subset of the URI, which uniquely references your key, for example:

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   Because OpenSSH uses the p11-kit-proxy wrapper and the OpenSC PKCS #11 module is registered to the p11-kit tool, you can simplify the previous command:

   $ ssh -i "pkcs11:id=%01" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   If you skip the id= part of a PKCS #11 URI, OpenSSH loads all keys that are available in the proxy module. This can reduce the amount of typing required:

   $ ssh -i pkcs11: <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

4. Optional: You can use the same URI string in the ~/.ssh/config file to make the configuration permanent:

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   The ssh client utility now automatically uses this URI and the key from the smart card.

Procedure

1. Create a new file in the /etc/polkit-1/rules.d/ directory:

   # touch /etc/polkit-1/rules.d/00-test.rules

2. Edit the file in an editor of your choice, for example:

   # vi /etc/polkit-1/rules.d/00-test.rules

3. Insert the following lines:

   polkit.addRule(function(action, subject) {
     if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
     	action.id == "org.debian.pcsc-lite.access_card") {
   	polkit.log("action=" + action);
   	polkit.log("subject=" + subject);
     }
   });

   Save the file, and exit the editor.

4. Restart the pcscd and polkit services:

   # systemctl restart pcscd.service pcscd.socket polkit.service

Verification

1. Make an authorization request for pcscd. For example, open the Firefox web browser or use the pkcs11-tool -L command provided by the opensc package.

2. Display the extended log entries, for example:

   # journalctl -u polkit --since "1 hour ago"
   polkitd[1224]: <no filename>:4: action=[Action id='org.debian.pcsc-lite.access_pcsc']
   polkitd[1224]: <no filename>:5: subject=[Subject pid=2020481 user=user' groups=user,wheel,mock,wireshark seat=null session=null local=true active=true]

Procedure

1. Find the ID of the security profile from the data stream file:

   $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
   Profiles:
   …
     Title: Australian Cyber Security Centre (ACSC) Essential Eight
   	Id: xccdf_org.ssgproject.content_profile_e8
     Title: Health Insurance Portability and Accountability Act (HIPAA)
   	Id: xccdf_org.ssgproject.content_profile_hipaa
     Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 10
   	Id: xccdf_org.ssgproject.content_profile_pci-dss
   …

2. Optional: If you want to customize your hardening with XCCDF Tailoring file you can use the autotailor command provided in the openscap-utils package. For more information, see Customizing a security profile with autotailor.

3. Generate the kickstart file from the SCAP source data stream:

   $ oscap xccdf generate fix --profile <profile_ID> --output <kickstart_file>.cfg --fix-type kickstart /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

   If you are using a tailoring file, embed the tailoring file into the generated kickstart file by using the --tailoring-file tailoring.xml option and your custom profile ID, for example:

   $ oscap xccdf generate fix --tailoring-file tailoring.xml --profile <custom_profile_ID> --output <kickstart_file>.cfg --fix-type kickstart ./ssg-rhel10-ds.xml

4. Review and, if necessary, manually modify the generated <kickstart_file>.cfg to fit the needs of your deployment. Follow the instructions in the comments in the file.

   Note

   Some changes might affect the compliance of the systems installed by the kickstart file. For example, some security policies require defined partitions or specific packages and services.

5. Use the kickstart file for your installation. For the installer to use the kickstart, the kickstart can be served through a web server, provided in PXE, or embedded into the ISO image. For detailed steps, see Installing RHEL fully and semi-automated in RHEL product documentation.
6. After the installation finishes, the system reboots automatically. After the reboot, log in and review the installation SCAP report saved in the /root directory.

Procedure

1. Create a tailoring file for your profile by using the autotailor command, for example:

   $ autotailor \ --select=<ruleID_1> \ --select=<ruleID_2> \ --unselect=<ruleID_3> \ --var-value=<valueID_1>=<value_1> \ --var-value=<valueID_2>=<value_2> \ --output=<tailoring.xml> \ --tailored-profile-id=<custom_profileID> \ /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml <profileID>

   Where:

   • <customization_options> are the modifications of the profile. Use one or more of the following options:

     --select=<ruleID>

     Add an existing rule to the profile.

     --unselect=<ruleID>

     Remove a rule from the profile.

     --var-value=<valueID>=<value>

     Override a pre-set value. For example, to set var_sshd_max_sessions to 10, use --var-value=var_sshd_max_sessions=10.

   • <tailoring.xml> is the file name where autotailor saves the tailoring.
   • <custom_profileID> is the profile ID within which the autotailor saves customizations, for example, custom_cis.
   • <profileID> is the profile ID with which the system should comply, for example, cis.
   Note

   For all profile, rule, and variable XCCDF IDs you can use either a full namespaced identifier or a shortened ID which autotailor automatically augments with the namespace prefix. For example, cis is equivalent to xccdf_org.ssgproject.content_profile_cis.

   You can override the default namespace org.ssgproject.content by using the --id-namespace option.

2. Optional: Create a tailoring file based on the customizations defined in the JSON Tailoring format:

   $ autotailor --output=<tailoring.xml> --json-tailoring=<json_tailoring.json>

   Replace:

   • <json_tailoring.json> with the file name with JSON Tailoring definitions.
   Note

   You can mix --json-tailoring with --select, --unselect, and --var-value command-line customizations. In that case, command-line customizations have priority over JSON Tailoring.

Procedure

1. Install the Keylime verifier:

   # dnf install keylime-verifier

2. Define the IP address and port of verifier by creating a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-verifier-ip.conf, with the following content:

   [verifier]
   ip = <verifier_IP_address>

   • Replace <verifier_IP_address> with the verifier’s IP address. Alternatively, use ip = * or ip = 0.0.0.0 to bind the verifier to all available IP addresses.
   • Optionally, you can also change the verifier’s port from the default value 8881 by using the port option.

3. Optional: Configure the verifier’s database for the list of agents. The default configuration uses an SQLite database in the verifier’s /var/lib/keylime/cv_data.sqlite/ directory. You can define a different database by creating a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-db-url.conf, with the following content:

   [verifier]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   Replace <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> with the URL of the database, for example, postgresql://verifier:UQ?nRNY9g7GZzN7@198.51.100.1/verifierdb.

   Ensure that the credentials you use provide the permissions for Keylime to create the database structure.

4. Add certificates and keys to the verifier. You can either let Keylime generate them, or use existing keys and certificates:

   • With the default tls_dir = generate option, Keylime generates new certificates for the verifier, registrar, and tenant in the /var/lib/keylime/cv_ca/ directory.

   • To load existing keys and certificates in the configuration, define their location in the verifier configuration. The certificates must be accessible by the keylime user, under which the Keylime services are running.

     Create a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-keys-and-certs.conf, with the following content:

     [verifier]
     tls_dir = /var/lib/keylime/cv_ca
     server_key = </path/to/server_key>
     server_key_password = <passphrase1>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
     client_key = </path/to/client_key>
     client_key_password = <passphrase2>
     client_cert = </path/to/client_cert>
     trusted_server_ca = ['</path/to/ca/cert3>', '</path/to/ca/cert4>']

     Note

     Use absolute paths to define key and certificate locations. Alternatively, relative paths are resolved from the directory defined in the tls_dir option.

5. Open the port in firewall:

   # firewall-cmd --add-port 8881/tcp
   # firewall-cmd --runtime-to-permanent

   If you use a different port, replace 8881 with the port number defined in the .conf file.

6. Start the verifier service:

   # systemctl enable --now keylime_verifier

   Note

   In the default configuration, start the keylime_verifier before starting the keylime_registrar service because the verifier creates the CA and certificates for the other Keylime components. This order is not necessary when you use custom certificates.

Procedure

1. Optional: Install the keylime-verifier package to access the configuration files. You can configure the container without this package, but it might be easier to modify the configuration files provided with the package.

   # dnf install keylime-verifier

2. Bind the verifier to all available IP addresses by creating a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-verifier-ip.conf, with the following content:

   [verifier]
   ip = *

   • Optionally, you can also change the verifier’s port from the default value 8881 by using the port option.

3. Optional: Configure the verifier’s database for the list of agents. The default configuration uses an SQLite database in the verifier’s /var/lib/keylime/cv_data.sqlite/ directory. You can define a different database by creating a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-db-url.conf, with the following content:

   [verifier]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   Replace <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> with the URL of the database, for example, postgresql://verifier:UQ?nRNY9g7GZzN7@198.51.100.1/verifierdb.

   Ensure that the credentials you use have the permissions for Keylime to create the database structure.

4. Add certificates and keys to the verifier. You can either let Keylime generate them, or use existing keys and certificates:

   • With the default tls_dir = generate option, Keylime generates new certificates for the verifier, registrar, and tenant in the /var/lib/keylime/cv_ca/ directory.

   • To load existing keys and certificates in the configuration, define their location in the verifier configuration. The certificates must be accessible by the keylime user, under which the Keylime processes are running.

     Create a new .conf file in the /etc/keylime/verifier.conf.d/ directory, for example, /etc/keylime/verifier.conf.d/00-keys-and-certs.conf, with the following content:

     [verifier]
     tls_dir = /var/lib/keylime/cv_ca
     server_key = </path/to/server_key>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
     client_key = </path/to/client_key>
     client_cert = </path/to/client_cert>
     trusted_server_ca = ['</path/to/ca/cert3>', '</path/to/ca/cert4>']

     Note

     Use absolute paths to define key and certificate locations. Alternatively, relative paths are resolved from the directory defined in the tls_dir option.

5. Open the port in firewall:

   # firewall-cmd --add-port 8881/tcp
   # firewall-cmd --runtime-to-permanent

   If you use a different port, replace 8881 with the port number defined in the .conf file.

6. Run the container:

   $ podman run --name keylime-verifier \
     -p 8881:8881 \
     -v /etc/keylime/verifier.conf.d:/etc/keylime/verifier.conf.d:Z \
     -v /var/lib/keylime/cv_ca:/var/lib/keylime/cv_ca:Z \
     -d \
     -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> \
     -e KEYLIME_VERIFIER_CLIENT_KEY_PASSWORD=<passphrase2> \
     registry.access.redhat.com/rhel9/keylime-verifier

   • The -p option opens the default port 8881 on the host and on the container.

   • The -v option creates a bind mount for the directory to the container.

     • With the Z option, Podman marks the content with a private unshared label. This means only the current container can use the private volume.
   • The -d option runs the container detached and in the background.
   • The option -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> defines the server key passphrase.
   • The option -e KEYLIME_VERIFIER_CLIENT_KEY_PASSWORD=<passphrase2> defines the client key passphrase.
   • You can override configuration options with environment variables by using the option -e KEYLIME_VERIFIER_<ENVIRONMENT_VARIABLE>=<value>. To modify additional options, insert the -e option separately for each environment variable. For a complete list of environment variables and their default values, see Keylime environment variables.

Procedure

1. Install the Keylime registrar:

   # dnf install keylime-registrar

2. Define the IP address and port of the registrar by creating a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-registrar-ip.conf, with the following content:

   [registrar]
   ip = <registrar_IP_address>

   • Replace <registrar_IP_address> with the registrar’s IP address. Alternatively, use ip = * or ip = 0.0.0.0 to bind the registrar to all available IP addresses.
   • Optionally, change the port to which the Keylime agents connect by using the port option. The default value is 8890.
   • Optionally, change the TLS port to which the Keylime verifier and tenant connect by using the tls_port option. The default value is 8891.

3. Optional: Configure the registrar’s database for the list of agents. The default configuration uses an SQLite database in the registrar’s /var/lib/keylime/reg_data.sqlite directory. You can create a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-db-url.conf, with the following content:

   [registrar]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   Replace <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> with the URL of the database, for example, postgresql://registrar:EKYYX-bqY2?#raXm@198.51.100.1/registrardb.

   Ensure that the credentials you use have the permissions for Keylime to create the database structure.

4. Add certificates and keys to the registrar:

   • You can use the default configuration and load the keys and certificates to the /var/lib/keylime/reg_ca/ directory.

   • Alternatively, you can define the location of the keys and certificates in the configuration. Create a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-keys-and-certs.conf, with the following content:

     [registrar]
     tls_dir = /var/lib/keylime/reg_ca
     server_key = </path/to/server_key>
     server_key_password = <passphrase1>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']

     Note

     Use absolute paths to define key and certificate locations. Alternatively, you can define a directory in the tls_dir option and use paths relative to that directory.

5. Open the ports in firewall:

   # firewall-cmd --add-port 8890/tcp --add-port 8891/tcp
   # firewall-cmd --runtime-to-permanent

   If you use a different port, replace 8890 or 8891 with the port number defined in the .conf file.

6. Start the keylime_registrar service:

   # systemctl enable --now keylime_registrar

   Note

   In the default configuration, start the keylime_verifier before starting the keylime_registrar service because the verifier creates the CA and certificates for the other Keylime components. This order is not necessary when you use custom certificates.

Procedure

1. Optional: Install the keylime-registrar package to access the configuration files. You can configure the container without this package, but it might be easier to modify the configuration files provided with the package.

   # dnf install keylime-registrar

2. Bind the registrar to all available IP addresses by creating a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-registrar-ip.conf, with the following content:

   [registrar]
   ip = *

   • Optionally, change the port to which the Keylime agents connect by using the port option. The default value is 8890.
   • Optionally, change the TLS port to which the Keylime tenant connects by using the tls_port option. The default value is 8891.

3. Optional: Configure the registrar’s database for the list of agents. The default configuration uses an SQLite database in the registrar’s /var/lib/keylime/reg_data.sqlite directory. You can create a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-db-url.conf, with the following content:

   [registrar]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   Replace <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> with the URL of the database, for example, postgresql://registrar:EKYYX-bqY2?#raXm@198.51.100.1/registrardb.

   Ensure that the credentials you use have the permissions for Keylime to create the database structure.

4. Add certificates and keys to the registrar:

   • You can use the default configuration and load the keys and certificates to the /var/lib/keylime/reg_ca/ directory.

   • Alternatively, you can define the location of the keys and certificates in the configuration. Create a new .conf file in the /etc/keylime/registrar.conf.d/ directory, for example, /etc/keylime/registrar.conf.d/00-keys-and-certs.conf, with the following content:

     [registrar]
     tls_dir = /var/lib/keylime/reg_ca
     server_key = </path/to/server_key>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']

     Note

     Use absolute paths to define key and certificate locations. Alternatively, you can define a directory in the tls_dir option and use paths relative to that directory.

5. Open the ports in firewall:

   # firewall-cmd --add-port 8890/tcp --add-port 8891/tcp
   # firewall-cmd --runtime-to-permanent

   If you use a different port, replace 8890 or 8891 with the port number defined in the .conf file.

6. Run the container:

   $ podman run --name keylime-registrar \
     -p 8890:8890 \
     -p 8891:8891 \
     -v /etc/keylime/registrar.conf.d:/etc/keylime/registrar.conf.d:Z \
     -v /var/lib/keylime/reg_ca:/var/lib/keylime/reg_ca:Z \
     -d \
     -e KEYLIME_REGISTRAR_SERVER_KEY_PASSWORD=<passphrase1> \
     registry.access.redhat.com/rhel9/keylime-registrar

   • The -p option opens the default ports 8890 and 8881 on the host and on the container.

   • The -v option creates a bind mount for the directory to the container.

     • With the Z option, Podman marks the content with a private unshared label. This means only the current container can use the private volume.
   • The -d option runs the container detached and in the background.
   • The option -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> defines the server key passphrase.
   • You can override configuration options with environment variables by using the option -e KEYLIME_REGISTRAR__<ENVIRONMENT_VARIABLE>=<value>. To modify additional options, insert the -e option separately for each environment variable. For a complete list of environment variables and their default values, see

Procedure

1. Create a playbook that defines the required role:

   1. Create a new YAML file and open it in a text editor, for example:

      # vi keylime-playbook.yml

   2. Insert the following content:

      ---
      - name: Manage keylime servers
        hosts: all
        vars:
          keylime_server_verifier_ip: "{{ ansible_host }}"
          keylime_server_registrar_ip: "{{ ansible_host }}"
          keylime_server_verifier_tls_dir: <ver_tls_directory>
          keylime_server_verifier_server_cert: <ver_server_certfile>
          keylime_server_verifier_server_key: <ver_server_key>
          keylime_server_verifier_server_key_passphrase: <ver_server_key_passphrase>
          keylime_server_verifier_trusted_client_ca: <ver_trusted_client_ca_list>
          keylime_server_verifier_client_cert: <ver_client_certfile>
          keylime_server_verifier_client_key: <ver_client_key>
          keylime_server_verifier_client_key_passphrase: <ver_client_key_passphrase>
          keylime_server_verifier_trusted_server_ca: <ver_trusted_server_ca_list>
          keylime_server_registrar_tls_dir: <reg_tls_directory>
          keylime_server_registrar_server_cert: <reg_server_certfile>
          keylime_server_registrar_server_key: <reg_server_key>
          keylime_server_registrar_server_key_passphrase: <reg_server_key_passphrase>
          keylime_server_registrar_trusted_client_ca: <reg_trusted_client_ca_list>
        roles:
          - rhel-system-roles.keylime_server

      You can find out more about the variables in Variables for the keylime_server RHEL system role.

2. Run the playbook:

   $ ansible-playbook <keylime-playbook.yml>

Verification

1. Check that the keylime_verifier service is active and running on the managed host:

   # systemctl status keylime_verifier
   ● keylime_verifier.service - The Keylime verifier
        Loaded: loaded (/usr/lib/systemd/system/keylime_verifier.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:08 EST; 1min 45s ago

2. Check that the keylime_registrar service is active and running:

   # systemctl status keylime_registrar
   ● keylime_registrar.service - The Keylime registrar service
        Loaded: loaded (/usr/lib/systemd/system/keylime_registrar.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:17 EST; 1min 42s ago
   ...

Procedure

1. Install the Keylime tenant:

   # dnf install keylime-tenant

2. Define the tenant’s connection to the Keylime verifier by editing the /etc/keylime/tenant.conf.d/00-verifier-ip.conf file:

   [tenant]
   verifier_ip = <verifier_ip>

   • Replace <verifier_ip> with the IP address to the verifier’s system.
   • If the verifier uses a different port than the default value 8881, add the verifier_port = <verifier_port> setting.

3. Define the tenant’s connection to the Keylime registrar by editing the /etc/keylime/tenant.conf.d/00-registrar-ip.conf file:

   [tenant]
   registrar_ip = <registrar_ip>

   • Replace <registrar_ip> with the IP address to the registrar’s system.
   • If the registrar uses a different port than the default value 8891, add the registrar_port = <registrar_port> setting.

4. Add certificates and keys to the tenant:

   1. You can use the default configuration and load the keys and certificates to the /var/lib/keylime/cv_ca directory.

   2. Alternatively, you can define the location of the keys and certificates in the configuration. Create a new .conf file in the /etc/keylime/tenant.conf.d/ directory, for example, /etc/keylime/tenant.conf.d/00-keys-and-certs.conf, with the following content:

      [tenant]
      tls_dir = /var/lib/keylime/cv_ca
      client_key = tenant-key.pem
      client_key_password = <passphrase1>
      client_cert = tenant-cert.pem
      trusted_server_ca = ['</path/to/ca/cert>']

      The trusted_server_ca parameter accepts paths to the verifier and registrar server CA certificate. You can provide multiple comma-separated paths, for example if the verifier and registrar use different CAs.

      Note

      Use absolute paths to define key and certificate locations. Alternatively, you can define a directory in the tls_dir option and use paths relative to that directory.

5. Optional: If the trusted platform module (TPM) endorsement key (EK) cannot be verified by using certificates in the /var/lib/keylime/tpm_cert_store directory, add the certificate to that directory. This can occur particularly when using virtual machines with emulated TPMs.

Verification

1. Check the status of the verifier:

   # keylime_tenant -c cvstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:08.155 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:08.157 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:08.178 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:08.178 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:08.221 - keylime.tenant - INFO - Verifier at 127.0.0.1 with Port 8881 does not have agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000.

   If correctly set up, and if no agent is configured, the verifier responds that it does not recognize the default agent UUID.

2. Check the status of the registrar:

   # keylime_tenant -c regstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:02.114 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:02.137 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:02.137 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:02.171 - keylime.registrar_client - CRITICAL - Error: could not get agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 data from Registrar Server: 404
   2022-10-14 12:56:02.172 - keylime.registrar_client - CRITICAL - Response code 404: agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 not found
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on the registrar. Please register the agent with the registrar.
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - {"code": 404, "status": "Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on registrar 127.0.0.1 port 8891.", "results": {}}

   If correctly set up, and if no agent is configured, the registrar responds that it does not recognize the default agent UUID.

Procedure

1. Install the Keylime agent:

   # dnf install keylime-agent

   This command installs the keylime-agent-rust package.

2. Define the agent’s IP address and port in the configuration files. Create a new .conf file in the /etc/keylime/agent.conf.d/ directory, for example, /etc/keylime/agent.conf.d/00-agent-ip.conf, with the following content:

   [agent]
   ip = '<agent_ip>'

   Note

   The Keylime agent configuration uses the TOML format, which is different from the INI format used for configuration of the other components. Therefore, enter values in valid TOML syntax, for example, paths in single quotation marks and arrays of multiple paths in square brackets.

   • Replace <agent_IP_address> with the agent’s IP address. Alternatively, use ip = '*' or ip = '0.0.0.0' to bind the agent to all available IP addresses.
   • Optionally, you can also change the agent’s port from the default value 9002 by using the port = '<agent_port>' option.

3. Define the registrar’s IP address and port in the configuration files. Create a new .conf file in the /etc/keylime/agent.conf.d/ directory, for example, /etc/keylime/agent.conf.d/00-registrar-ip.conf, with the following content:

   [agent]
   registrar_ip = '<registrar_IP_address>'

   • Replace <registrar_IP_address> with the registrar’s IP address.
   • Optionally, you can also change the registrar’s port from the default value 8890 by using the registrar_port = '<registrar_port>' option.

4. Optional: Define the agent’s universally unique identifier (UUID). If it is not defined, the default UUID is used. Create a new .conf file in the /etc/keylime/agent.conf.d/ directory, for example, /etc/keylime/agent.conf.d/00-agent-uuid.conf, with the following content:

   [agent]
   uuid = '<agent_UUID>'

   • Replace <agent_UUID> with the agent’s UUID, for example d432fbb3-d2f1-4a97-9ef7-abcdef012345. You can use the uuidgen utility to generate a UUID.

5. Optional: Load existing keys and certificates for the agent. If the agent receives no server_key and server_cert, it generates its own key and a self-signed certificate.

   Define the location of the keys and certificates in the configuration. Create a new .conf file in the /etc/keylime/agent.conf.d/ directory, for example, /etc/keylime/agent.conf.d/00-keys-and-certs.conf, with the following content:

   [agent]
   server_key = '</path/to/server_key>'
   server_key_password = '<passphrase1>'
   server_cert = '</path/to/server_cert>'
   trusted_client_ca = '[</path/to/ca/cert3>, </path/to/ca/cert4>]'

   Note

   Use absolute paths to define key and certificate locations. The Keylime agent does not accept relative paths.

6. Open the port in firewall:

   # firewall-cmd --add-port 9002/tcp
   # firewall-cmd --runtime-to-permanent

   If you use a different port, replace 9002 with the port number defined in the .conf file.

7. Enable and start the keylime_agent service:

   # systemctl enable --now keylime_agent

8. Optional: From the system where the Keylime tenant is configured, verify that the agent is correctly configured and can connect to the registrar.

   # keylime_tenant -c regstatus --uuid <agent_uuid>
   Reading configuration from ['/etc/keylime/logging.conf']
   ...
   ==\n-----END CERTIFICATE-----\n", "ip": "127.0.0.1", "port": 9002, "regcount": 1, "operational_state": "Registered"}}}

   • Replace <agent_uuid> with the agent’s UUID.

     If the registrar and agent are correctly configured, the output displays the agent’s IP address and port, followed by "operational_state": "Registered".

9. Create a new IMA policy by entering the following content into the /etc/ima/ima-policy file:

   # PROC_SUPER_MAGIC = 0x9fa0
   dont_measure fsmagic=0x9fa0
   # SYSFS_MAGIC = 0x62656572
   dont_measure fsmagic=0x62656572
   # DEBUGFS_MAGIC = 0x64626720
   dont_measure fsmagic=0x64626720
   # TMPFS_MAGIC = 0x01021994
   dont_measure fsmagic=0x1021994
   # RAMFS_MAGIC
   dont_measure fsmagic=0x858458f6
   # DEVPTS_SUPER_MAGIC=0x1cd1
   dont_measure fsmagic=0x1cd1
   # BINFMTFS_MAGIC=0x42494e4d
   dont_measure fsmagic=0x42494e4d
   # SECURITYFS_MAGIC=0x73636673
   dont_measure fsmagic=0x73636673
   # SELINUX_MAGIC=0xf97cff8c
   dont_measure fsmagic=0xf97cff8c
   # SMACK_MAGIC=0x43415d53
   dont_measure fsmagic=0x43415d53
   # NSFS_MAGIC=0x6e736673
   dont_measure fsmagic=0x6e736673
   # EFIVARFS_MAGIC
   dont_measure fsmagic=0xde5e81e4
   # CGROUP_SUPER_MAGIC=0x27e0eb
   dont_measure fsmagic=0x27e0eb
   # CGROUP2_SUPER_MAGIC=0x63677270
   dont_measure fsmagic=0x63677270
   # OVERLAYFS_MAGIC
   # when containers are used we almost always want to ignore them
   dont_measure fsmagic=0x794c7630
   # MEASUREMENTS
   measure func=BPRM_CHECK
   measure func=FILE_MMAP mask=MAY_EXEC
   measure func=MODULE_CHECK uid=0

   This policy targets runtime monitoring of executed applications. You can adjust this policy according to your scenario. You can find the MAGIC constants in the statfs(2) man page.

10. Update kernel parameters:

    # grubby --update-kernel DEFAULT --args 'ima_appraise=fix ima_canonical_fmt ima_policy=tcb ima_template=ima-ng'

11. Reboot the system to apply the new IMA policy.

Verification

1. Verify that the agent is running:

   # systemctl status keylime_agent
   ● keylime_agent.service - The Keylime compute agent
        Loaded: loaded (/usr/lib/systemd/system/keylime_agent.service; enabled; preset: disabled)
        Active: active (running) since ...

Procedure

1. On the monitored system where the Keylime agent is configured and running, generate an allowlist from the current state of the system:

   # /usr/share/keylime/scripts/create_allowlist.sh -o <allowlist.txt> -h sha256sum

   Replace <allowlist.txt> with the file name of the allowlist.

   Important

   Use the SHA-256 hash function. SHA-1 is not secure and has been deprecated in RHEL 9. For additional information, see SHA-1 deprecation in Red Hat Enterprise Linux 9.

2. Copy the generated allowlist to the system where the keylime_tenant utility is configured, for example:

   # scp <allowlist.txt> root@<tenant.ip>:/root/<allowlist.txt>

3. Optional: You can define a list of files or directories excluded from Keylime measurements by creating a file on the tenant system and entering the paths of files and directories to exclude. The excludelist accepts Python regular expressions with one regular expression per line. See Regular expression operations at docs.python.org for the complete list of special characters. Save the excludelist on the tenant system.

4. Combine the allowlist and excludelist into the Keylime runtime policy:

   # keylime_create_policy -a <allowlist.txt> -e <excludelist.txt> -o <policy.json>

5. On the system where the Keylime tenant is configured, provision the agent by using the keylime_tenant utility:

   # keylime_tenant -c add -t <agent_ip> -u <agent_uuid> --runtime-policy <policy.json> --cert default

   • Replace <agent_ip> with the agent’s IP address.
   • Replace <agent_uuid> with the agent’s UUID.
   • Replace <policy.json> with the path to the Keylime runtime policy file.

   • With the --cert option, the tenant generates and signs a certificate for the agent by using the CA certificates and keys located in the specified directory, or the default /var/lib/keylime/ca/ directory. If the directory contains no CA certificates and keys, the tenant will generate them automatically according to the configuration in the /etc/keylime/ca.conf file and save them to the specified directory. The tenant then sends these keys and certificates to the agent.

     When generating CA certificates or signing agent certificates, you might be prompted for the password to access the CA private key: Please enter the password to decrypt your keystore:.

     If you do not want to use a certificate, use the -f option instead for delivering a file to the agent. Provisioning an agent requires sending any file, even an empty file.

     Note

     Keylime encrypts the file sent to the agent, and decrypts it only if the agent’s system complies with the TPM policy and the IMA allowlist. By default, Keylime decompresses sent .zip files.

   As an example, with the following command, keylime_tenant provisions a new Keylime agent at 127.0.0.1 with UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000 and loads a runtime policy policy.json. It also generates a certificate in the default directory and sends the certificate file to the agent. Keylime decrypts the file only if the TPM policy configured in /etc/keylime/verifier.conf is satisfied:

   # keylime_tenant -c add -t 127.0.0.1 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 --runtime-policy policy.json --cert default

   Note

   You can stop Keylime from monitoring a node by using the # keylime_tenant -c delete -u <agent_uuid> command.

   You can modify the configuration of an already registered agent by using the keylime_tenant -c update command.

Verification

1. Optional: Reboot the monitored system to verify that the settings are persistent.

2. Verify a successful attestation of the agent:

   # keylime_tenant -c cvstatus -u <agent.uuid>
   ...
   {"<agent.uuid>": {"operational_state": "Get Quote"..."attestation_count": 5
   ...

   Replace <agent.uuid> with the agent’s UUID.

   If the value of operational_state is Get Quote and attestation_count is nonzero, the attestation of this agent is successful.

   If the value of operational_state is Invalid Quote or Failed attestation fails, the command displays output similar to the following:

   {"<agent.uuid>": {"operational_state": "Invalid Quote", ... "ima.validation.ima-ng.not_in_allowlist", "attestation_count": 5, "last_received_quote": 1684150329, "last_successful_attestation": 1684150327}}

3. If the attestation fails, display more details in the verifier log:

   # journalctl -u keylime_verifier
   keylime.tpm - INFO - Checking IMA measurement list...
   keylime.ima - WARNING - File not found in allowlist: /root/bad-script.sh
   keylime.ima - ERROR - IMA ERRORS: template-hash 0 fnf 1 hash 0 good 781
   keylime.cloudverifier - WARNING - agent D432FBB3-D2F1-4A97-9EF7-75BD81C00000 failed, stopping polling

Procedure

1. On the monitored system where the Keylime agent is configured and running, install the python3-keylime package, which contains the create_mb_refstate script:

   # dnf -y install python3-keylime

2. On the monitored system, generate a policy from the measured boot log of the current state of the system by using the create_mb_refstate script:

   # /usr/share/keylime/scripts/create_mb_refstate /sys/kernel/security/tpm0/binary_bios_measurements <./measured_boot_reference_state.json>

   • Replace <./measured_boot_reference_state.json> with the path where the script saves the generated policy.

   • If your UEFI system does not have Secure Boot enabled, pass the --without-secureboot argument.

     Important

     The policy generated with the create_mb_refstate script is based on the current state of the system and is very strict. Any modifications of the system including kernel updates and system updates will change the boot process and the system will fail the attestation.

3. Copy the generated policy to the system where the keylime_tenant utility is configured, for example:

   # scp root@<agent_ip>:<./measured_boot_reference_state.json> <./measured_boot_reference_state.json>

4. On the system where the Keylime tenant is configured, provision the agent by using the keylime_tenant utility:

   # keylime_tenant -c add -t <agent_ip> -u <agent_uuid> --mb_refstate <./measured_boot_reference_state.json> --cert default

   • Replace <agent_ip> with the agent’s IP address.
   • Replace <agent_uuid> with the agent’s UUID.
   • Replace <./measured_boot_reference_state.json> with the path to the measured boot policy.

   If you configure measured boot in combination with runtime monitoring, provide all the options from both use cases when entering the keylime_tenant -c add command.

   Note

   You can stop Keylime from monitoring a node by using the # keylime_tenant -c delete -t <agent_ip> -u <agent_uuid> command.

   You can modify the configuration of an already registered agent by using the keylime_tenant -c update command.

Verification

1. Reboot the monitored system and verify a successful attestation of the agent:

   # keylime_tenant -c cvstatus -u <agent_uuid>
   ...
   {"<agent.uuid>": {"operational_state": "Get Quote"..."attestation_count": 5
   ...

   Replace <agent_uuid> with the agent’s UUID.

   If the value of operational_state is Get Quote and attestation_count is nonzero, the attestation of this agent is successful.

   If the value of operational_state is Invalid Quote or Failed attestation fails, the command displays output similar to the following:

   {"<agent.uuid>": {"operational_state": "Invalid Quote", ... "ima.validation.ima-ng.not_in_allowlist", "attestation_count": 5, "last_received_quote": 1684150329, "last_successful_attestation": 1684150327}}

2. If the attestation fails, display more details in the verifier log:

   # journalctl -u keylime_verifier
   {"d432fbb3-d2f1-4a97-9ef7-75bd81c00000": {"operational_state": "Tenant Quote Failed", ... "last_event_id": "measured_boot.invalid_pcr_0", "attestation_count": 0, "last_received_quote": 1684487093, "last_successful_attestation": 0}}

Procedure

1. Install the aide package:

   # dnf install aide

2. Generate an initial database:

   # aide --init
   Start timestamp: 2024-07-08 10:39:23 -0400 (AIDE 0.16)
   AIDE initialized database at /var/lib/aide/aide.db.new.gz
   
   Number of entries:	55856
   
   ---------------------------------------------------
   The attributes of the (uncompressed) database(s):
   ---------------------------------------------------
   
   /var/lib/aide/aide.db.new.gz
   …
     SHA512   : mZaWoGzL2m6ZcyyZ/AXTIowliEXWSZqx
                IFYImY4f7id4u+Bq8WeuSE2jasZur/A4
                FPBFaBkoCFHdoE/FW/V94Q==

3. Optional: In the default configuration, the aide --init command checks just a set of directories and files defined in the /etc/aide.conf file. To include additional directories or files in the AIDE database, and to change their watched parameters, edit /etc/aide.conf accordingly.

4. To start using the database, remove the .new substring from the initial database file name:

   # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

5. Optional: To change the location of the AIDE database, edit the /etc/aide.conf file and modify the DBDIR value. For additional security, store the database, configuration, and the /usr/sbin/aide binary file in a secure location such as a read-only media.

Procedure

1. To initiate a manual check:

   # aide --check
   Start timestamp: 2024-07-08 10:43:46 -0400 (AIDE 0.16)
   AIDE found differences between database and file system!!
   
   Summary:
     Total number of entries:	55856
     Added entries:		0
     Removed entries:		0
     Changed entries:		1
   
   ---------------------------------------------------
   Changed entries:
   ---------------------------------------------------
   
   f   ...      ..S : /root/.viminfo
   
   ---------------------------------------------------
   Detailed information about changes:
   ---------------------------------------------------
   
   File: /root/.viminfo
     SELinux  : system_u:object_r:admin_home_t:s | unconfined_u:object_r:admin_home
                0                                | _t:s0
   …

2. At a minimum, configure the system to run AIDE weekly. Optimally, run AIDE daily. For example, to schedule a daily execution of AIDE at 04:05 a.m. by using the cron command, add the following line to the /etc/crontab file:

    05 4 * * * root /usr/sbin/aide --check

Procedure

1. Update your baseline AIDE database:

   # aide --update

   The aide --update command creates the /var/lib/aide/aide.db.new.gz database file.

2. To start using the updated database for integrity checks, remove the .new substring from the file name.

Procedure

1. To install the tang package and its dependencies, enter the following command as root:

   # dnf install tang

2. Pick an unoccupied port, for example, 7500/tcp, and allow the tangd service to bind to that port:

   # semanage port -a -t tangd_port_t -p tcp 7500

   Note that a port can be used only by one service at a time, and thus an attempt to use an already occupied port implies the ValueError: Port already defined error message.

3. Open the port in the firewall:

   # firewall-cmd --add-port=7500/tcp
   # firewall-cmd --runtime-to-permanent

4. Enable the tangd service:

   # systemctl enable tangd.socket

5. Create an override file:

   # systemctl edit tangd.socket

6. In the following editor screen, which opens an empty override.conf file located in the /etc/systemd/system/tangd.socket.d/ directory, change the default port for the Tang server from 80 to the previously picked number by adding the following lines:

   [Socket]
   ListenStream=
   ListenStream=7500

   Important

   Insert the previous code snippet between the lines starting with # Anything between here and # Lines below this, otherwise the system discards your changes.

7. Save the changes by pressing Ctrl+O and Enter. Exit the editor by pressing Ctrl+X.

8. Reload the changed configuration:

   # systemctl daemon-reload

9. Check that your configuration is working:

   # systemctl show tangd.socket -p Listen
   Listen=[::]:7500 (Stream)

10. Start the tangd service:

    # systemctl restart tangd.socket

    Because tangd uses the systemd socket activation mechanism, the server starts as soon as the first connection comes in. A new set of cryptographic keys is automatically generated at the first start. To perform cryptographic operations such as manual key generation, use the jose utility.

Procedure

1. Rename all keys in the /var/db/tang key database directory to have a leading . to hide them from advertisement. Note that the file names in the following example differs from unique file names in the key database directory of your Tang server:

   # cd /var/db/tang
   # ls -l
   -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
   # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk

2. Check that you renamed and therefore hid all keys from the Tang server advertisement:

   # ls -l
   total 0

3. Generate new keys using the /usr/libexec/tangd-keygen command in /var/db/tang on the Tang server:

   # /usr/libexec/tangd-keygen /var/db/tang
   # ls /var/db/tang
   3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk

4. Check that your Tang server advertises the signing key from the new key pair, for example:

   # tang-show-keys 7500
   3ZWS6-cDrCG61UPJS2BMmPU4I54

5. On your NBDE clients, use the clevis luks report command to check if the keys advertised by the Tang server remains the same. You can identify slots with the relevant binding using the clevis luks list command, for example:

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv"}'
   # clevis luks report -d /dev/sda2 -s 1
   ...
   Report detected that some keys were rotated.
   Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]

6. To regenerate LUKS metadata for the new keys either press y to the prompt of the previous command, or use the clevis luks regen command:

   # clevis luks regen -d /dev/sda2 -s 1

7. When you are sure that all old clients use the new keys, you can remove the old keys from the Tang server, for example:

   # cd /var/db/tang
   # rm .*.jwk

Procedure

1. Log in to the RHEL 10 web console.

   For details, see Logging in to the web console.

2. Switch to administrative access, provide your credentials, and click Storage. In the Storage table, click the disk that contains an encrypted volume you plan to add to unlock automatically.

3. In the following page with details of the selected disk, click + in the Keys section to add a Tang key:

   

4. Select Tang keyserver as Key source, provide the address of your Tang server, and a password that unlocks the LUKS-encrypted device. Click Add to confirm:

   

   The following dialog window provides a command to verify that the key hash matches.

5. In a terminal on the Tang server, use the tang-show-keys command to display the key hash for comparison. In this example, the Tang server is running on the port 7500:

   # tang-show-keys 7500
   x100_1k6GPiDOaMlL3WbpCjHOy9ul1bSfdhI3M08wO0

6. Click Trust key when the key hashes in the web console and in the output of previously listed commands are the same:

   

Verification

1. Check that the newly added Tang key is now listed in the Keys section with the Keyserver type:

   

2. Verify that the bindings are available for the early boot, for example:

   # lsinitrd | grep clevis-luks
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path
   …

Procedure

1. To automatically unlock an existing LUKS-encrypted volume, install the clevis-luks subpackage:

   # dnf install clevis-luks

2. Identify the LUKS-encrypted volume for PBD. In the following example, the block device is referred as /dev/sda2:

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. Bind the volume to a Tang server using the clevis luks bind command:

   # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
   The advertisement contains the following signing keys:
   
   _OsIk0T-E2l6qjfdDiwVmidoZjA
   
   Do you wish to trust these keys? [ynYN] y
   You are about to initialize a LUKS device for metadata storage.
   Attempting to initialize it may result in data loss if data was
   already written into the LUKS header gap in a different format.
   A backup is advised before initialization is performed.
   
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   This command performs four steps:

   1. Creates a new key with the same entropy as the LUKS master key.
   2. Encrypts the new key with Clevis.
   3. Stores the Clevis JWE object in the LUKS2 header token or uses LUKSMeta if the non-default LUKS1 header is used.
   4. Enables the new key for use with LUKS.
   Note

   The binding procedure assumes that the header contains at least one free LUKS password slot. The clevis luks bind command takes one of the slots.

   Now, you can unlock the volume with your existing password as well as with the Clevis policy.

4. To enable the early boot system to process the disk binding, use the dracut tool on an already installed system. In RHEL, Clevis produces a generic initrd (initial RAM disk) without host-specific configuration options and does not automatically add parameters such as rd.neednet=1 to the kernel command line. If your configuration relies on a Tang pin that requires network during early boot, use the --hostonly-cmdline argument and dracut adds rd.neednet=1 when it detects a Tang binding:

   1. Install the clevis-dracut package:

      # dnf install clevis-dracut

   2. Regenerate the initial RAM disk:

      # dracut -fv --regenerate-all --hostonly-cmdline

   3. Alternatively, create a .conf file in the /etc/dracut.conf.d/ directory, and add the hostonly_cmdline=yes option to the file. Then, you can use dracut without --hostonly-cmdline, for example:

      # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf
      # dracut -fv --regenerate-all

   4. You can also ensure that networking for a Tang pin is available during early boot by using the grubby tool on the system where Clevis is installed:

      # grubby --update-kernel=ALL --args="rd.neednet=1"

Verification

1. Verify that the Clevis JWE object is successfully placed in a LUKS header, use the clevis luks list command:

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv:port"}'

2. Check that the bindings are available for the early boot, for example:

   # lsinitrd | grep clevis-luks
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path
   …

Procedure

1. You can provide your static network configuration as a value for the kernel-cmdline option in a dracut command, for example:

   # dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"

2. Alternatively, create a .conf file in the /etc/dracut.conf.d/ directory with the static network information and then, regenerate the initial RAM disk image:

   # cat /etc/dracut.conf.d/static_ip.conf
   kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"
   # dracut -fv --regenerate-all

Procedure

1. To automatically unlock an existing LUKS-encrypted volume, install the clevis-luks subpackage:

   # dnf install clevis-luks

2. Identify the LUKS-encrypted volume for PBD. In the following example, the block device is referred as /dev/sda2:

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. Bind the volume to a TPM 2.0 device using the clevis luks bind command, for example:

   # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
   ...
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   This command performs four steps:

   1. Creates a new key with the same entropy as the LUKS master key.
   2. Encrypts the new key with Clevis.
   3. Stores the Clevis JWE object in the LUKS2 header token or uses LUKSMeta if the non-default LUKS1 header is used.

   4. Enables the new key for use with LUKS.

      Note

      The binding procedure assumes that there is at least one free LUKS password slot. The clevis luks bind command takes one of the slots.

      Alternatively, if you want to seal data to specific Platform Configuration Registers (PCR) states, add the pcr_bank and pcr_ids values to the clevis luks bind command, for example:

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"0,1"}'

      Important

      Because the data can only be unsealed if PCR hashes values match the policy used when sealing and the hashes can be rewritten, add a strong passphrase that enable you to unlock the encrypted volume manually when a value in a PCR changes.

      If the system cannot automatically unlock your encrypted volume after an upgrade of the shim-x64 package, follow the steps in the Clevis TPM2 no longer decrypts LUKS devices after a restart KCS article.

4. The volume can now be unlocked with your existing password as well as with the Clevis policy.

5. To enable the early boot system to process the disk binding, use the dracut tool on an already installed system:

   # dnf install clevis-dracut
   # dracut -fv --regenerate-all

Verification

1. To verify that the Clevis JWE object is successfully placed in a LUKS header, use the clevis luks list command:

   # clevis luks list -d /dev/sda2
   1: tpm2 '{"hash":"sha256","key":"rsa"}'

Procedure

1. Check which LUKS version the volume, for example /dev/sda2, is encrypted by and identify a slot and a token that is bound to Clevis:

   # cryptsetup luksDump /dev/sda2
   LUKS header information
   Version:        2
   ...
   Keyslots:
     0: luks2
   ...
   1: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
   ...
         Tokens:
           0: clevis
                 Keyslot:  1
   ...

   In the previous example, the Clevis token is identified by 0 and the associated key slot is 1.

2. In case of LUKS2 encryption, remove the token:

   # cryptsetup token remove --token-id 0 /dev/sda2

3. If your device is encrypted by LUKS1, which is indicated by the Version: 1 string in the output of the cryptsetup luksDump command, perform this additional step with the luksmeta wipe command:

   # luksmeta wipe -d /dev/sda2 -s 1

4. Wipe the key slot containing the Clevis passphrase:

   # cryptsetup luksKillSlot /dev/sda2 1

Procedure

1. Instruct Kickstart to partition the disk such that LUKS encryption has enabled for all mount points, other than /boot, with a temporary password. The password is temporary for this step of the enrollment process.

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

   Note that OSPP-compliant systems require a more complex configuration, for example:

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
   part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
   part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

2. Install the related Clevis packages by listing them in the %packages section:

   %packages
   clevis-dracut
   clevis-luks
   clevis-systemd
   %end

3. Optional: To ensure that you can unlock the encrypted volume manually when required, add a strong passphrase before you remove the temporary passphrase. See the How to add a passphrase, key, or keyfile to an existing LUKS device article for more information.

4. Call clevis luks bind to perform binding in the %post section. Afterward, remove the temporary password:

   %post
   clevis luks bind -y -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   If your configuration relies on a Tang pin that requires network during early boot or you use NBDE clients with static IP configurations, you have to modify the dracut command as described in Configuring NBDE clients with static IP configuration.

   Warning

   The cryptsetup luksRemoveKey command prevents any further administration of a LUKS2 device on which you apply it. You can recover a removed master key using the dmsetup command only for LUKS1 devices.

Procedure

1. To automatically unlock a LUKS-encrypted removable storage device, such as a USB drive, install the clevis-udisks2 package:

   # dnf install clevis-udisks2

2. Reboot the system, and then perform the binding step using the clevis luks bind command as described in Configuring NBDE clients for automated unlocking of LUKS-encrypted volumes, for example:

   # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

3. The LUKS-encrypted removable device can be now unlocked automatically in your GNOME desktop session. The device bound to a Clevis policy can be also unlocked by the clevis luks unlock command:

   # clevis luks unlock -d /dev/sdb1

Procedure

1. Pull the tang container image from the registry.redhat.io registry:

   # podman pull registry.redhat.io/rhel10/tang

2. Run the container, specify its port, and specify the path to the Tang keys. The previous example runs the tang container, specifies the port 7500, and indicates a path to the Tang keys of the /var/db/tang directory:

   # podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel10/tang

   Note that Tang uses port 80 by default but this may collide with other services such as the Apache HTTP server.

3. Optional: For increased security, rotate the Tang keys periodically. You can use the tangd-rotate-keys script, for example:

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel10/tang tangd-rotate-keys -v -d /var/db/tang
   Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
   Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
   Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
   Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
   Keys rotated successfully.

Procedure

1. Install the fapolicyd package:

   # dnf install fapolicyd

2. Optional: To try your configuration first, change mode to permissive.

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

      # vi /etc/fapolicyd/fapolicyd.conf

   2. Change the value of the permissive option from 0 to 1, save the file, and exit the editor:

      permissive = 1

      Alternatively, you can debug your configuration by using the fapolicyd --debug-deny --permissive command before you start the service. See the Troubleshooting problems related to fapolicyd section for more information.

3. Enable and start the fapolicyd service:

   # systemctl enable --now fapolicyd

4. If you enabled permissive mode through /etc/fapolicyd/fapolicyd.conf:

   1. Set the Audit service for recording fapolicyd events:

      # auditctl -w /etc/fapolicyd/ -p wa -k fapolicyd_changes
      # service try-restart auditd

   2. Use your applications.

   3. Check Audit logs for fanotify denials, for example:

      # ausearch -ts recent -m fanotify

   4. When debugged, disable permissive mode by changing the corresponding value back to permissive = 0, and restart the service:

      # systemctl restart fapolicyd

Verification

1. Verify that the fapolicyd service is running correctly:

   # systemctl status fapolicyd
   ● fapolicyd.service - File Access Policy Daemon
        Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; preset: disabled)
        Active: active (running) since Tue 2024-10-08 05:53:50 EDT; 11s ago
   …
   Oct 08 05:53:51 machine1.example.com fapolicyd[4974]: Loading trust data from rpmdb backend
   Oct 08 05:53:51 machine1.example.com fapolicyd[4974]: Loading trust data from file backend
   Oct 08 05:53:51 machine1.example.com fapolicyd[4974]: Starting to listen for events

2. Log in as a user without root privileges, and check that fapolicyd is working, for example:

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

Procedure

1. Copy your custom binary to the required directory, for example:

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. Mark your custom binary as trusted, and store the corresponding entry to the myapp file in /etc/fapolicyd/trust.d/:

   # fapolicyd-cli --file add /tmp/ls --trust-file myapp

   • If you skip the --trust-file option, then the previous command adds the corresponding line to /etc/fapolicyd/fapolicyd.trust.
   • To mark all existing files in a directory as trusted, provide the directory path as an argument of the --file option, for example: fapolicyd-cli --file add /tmp/my_bin_dir/ --trust-file myapp.

3. Update the fapolicyd database:

   # fapolicyd-cli --update

Verification

1. Check that your custom binary can be now executed, for example:

   $ /tmp/ls
   ls

Procedure

1. Copy your custom binary to the required directory, for example:

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. Stop the fapolicyd service:

   # systemctl stop fapolicyd

3. Use debug mode to identify a corresponding rule. Because the output of the fapolicyd --debug command is verbose and you can stop it only by pressing Ctrl+C or killing the corresponding process, redirect the error output to a file. In this case, you can limit the output only to access denials by using the --debug-deny option instead of --debug:

   # fapolicyd --debug-deny 2> fapolicy.output &
   [1] 51341

   Alternatively, you can run fapolicyd debug mode in another terminal.

4. Repeat the command that fapolicyd denied:

   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

5. Stop debug mode by resuming it in the foreground and pressing Ctrl+C:

   # fg
   fapolicyd --debug 2> fapolicy.output
   ^C
   ...

   Alternatively, kill the process of fapolicyd debug mode:

   # kill 51341

6. Find a rule that denies the execution of your application:

   # cat fapolicy.output | grep 'deny_audit'
   ...
   rule=13 dec=deny_audit perm=execute auid=0 pid=6855 exe=/usr/bin/bash : path=/tmp/ls ftype=application/x-executable trust=0

7. Locate the file that contains a rule that prevented the execution of your custom binary. In this case, the deny_audit perm=execute rule belongs to the 90-deny-execute.rules file:

   # ls /etc/fapolicyd/rules.d/
   10-languages.rules  40-bad-elf.rules	   72-shell.rules
   20-dracut.rules     41-shared-obj.rules    90-deny-execute.rules
   21-updaters.rules   42-trusted-elf.rules   95-allow-open.rules
   30-patterns.rules   70-trusted-lang.rules
   
   
   # cat /etc/fapolicyd/rules.d/90-deny-execute.rules
   # Deny execution for anything untrusted
   
   deny_audit perm=execute all : all

8. Add a new allow rule to the file that lexically precedes the rule file that contains the rule that denied the execution of your custom binary in the /etc/fapolicyd/rules.d/ directory:

   # touch /etc/fapolicyd/rules.d/80-myapps.rules
   # vi /etc/fapolicyd/rules.d/80-myapps.rules

   Insert the following rule to the 80-myapps.rules file:

   allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

   Alternatively, you can allow executions of all binaries in the /tmp directory by adding the following rule to the rule file in /etc/fapolicyd/rules.d/:

   allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ trust=0

   Important

   To make a rule effective recursively on all directories under the specified directory, add a trailing slash to the value of the dir= parameter in the rule (/tmp/ in the previous example).

9. To prevent changes in the content of your custom binary, define the required rule using an SHA-256 checksum:

   $ sha256sum /tmp/ls
   780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

   Change the rule to the following definition:

   allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836

10. Check that the list of compiled differs from the rule set in /etc/fapolicyd/rules.d/, and update the list, which is stored in the /etc/fapolicyd/compiled.rules file:

    # fagenrules --check
    /usr/sbin/fagenrules: Rules have changed and should be updated
    # fagenrules --load

11. Check that your custom rule is in the list of fapolicyd rules before the rule that prevented the execution:

    # fapolicyd-cli --list
    ...
    13. allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0
    14. deny_audit perm=execute all : all
    ...

12. Start the fapolicyd service:

    # systemctl start fapolicyd

Verification

1. Check that your custom binary can be now executed, for example:

   $ /tmp/ls
   ls

Procedure

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

   # vi /etc/fapolicyd/fapolicyd.conf

2. Change the value of the integrity option from none to sha256, save the file, and exit the editor:

   integrity = sha256

3. Restart the fapolicyd service:

   # systemctl restart fapolicyd

Verification

1. Back up the file used for the verification:

   # cp /bin/more /bin/more.bak

2. Change the content of the /bin/more binary:

   # cat /bin/less > /bin/more

3. Use the changed binary as a regular user:

   # su example.user
   $ /bin/more /etc/redhat-release
   bash: /bin/more: Operation not permitted

4. Revert the changes:

   # mv -f /bin/more.bak /bin/more

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuring fapolicyd
     hosts: managed-node-01.example.com
     tasks:
       - name: Allow only executables installed from RPM database and specific files
         ansible.builtin.include_role:
           name: rhel-system-roles.fapolicyd
         vars:
           fapolicyd_setup_permissive: false
           fapolicyd_setup_integrity: sha256
           fapolicyd_setup_trust: rpmdb,file
           fapolicyd_add_trusted_file:
             - <path_to_allowed_command>
             - <path_to_allowed_service>

   The settings specified in the example playbook include the following:

   fapolicyd_setup_permissive: <true|false>

   Enables or disables sending policy decisions to the kernel for enforcement. Set this variable for debugging and testing purposes to false.

   fapolicyd_setup_integrity: <type_type>

   Defines the integrity checking method. You can set one of the following values:

   • none (default): Disables integrity checking.
   • size: The service compares only the file sizes of allowed applications.
   • ima: The service checks the SHA-256 hash that the kernel’s Integrity Measurement Architecture (IMA) stored in a file’s extended attribute. Additionally, the service performs a size check. Note that the role does not configure the IMA kernel subsystem. To use this option, you must manually configure the IMA subsystem.
   • sha256: The service compares the SHA-256 hash of allowed applications.

   fapolicyd_setup_trust: <trust_backends>

   Defines the list of trust backends. If you include the file backend, specify the allowed executable files in the fapolicyd_add_trusted_file list.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.fapolicyd.README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook ~/playbook.yml --syntax-check

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml