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. To switch the system to FIPS mode:

   # fips-mode-setup --enable
   Kernel initramdisks are being regenerated. This might take some time.
   Setting system policy to FIPS
   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.
   FIPS mode will be enabled.
   Please reboot the system for the setting to take effect.

2. Restart your system to allow the kernel to switch to FIPS mode:

   # reboot

Verification

1. After the restart, you can check the current state of FIPS mode:

   # fips-mode-setup --check
   FIPS mode is enabled.

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. 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. 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 new playbook.yml file with the following content:

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: rhel-system-roles.crypto_policies
       vars:
         - crypto_policies_policy: FUTURE
         - crypto_policies_reboot_ok: true

   You can replace the FUTURE value with your preferred crypto policy, for example: DEFAULT, LEGACY, and FIPS:OSPP.

   The crypto_policies_reboot_ok: true variable causes the system to reboot after the System Role changes the cryptographic policy.

   For more details, see Crypto Policies System Role variables and facts .

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file playbook.yml

Verification

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

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: rhel-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   This playbook does not change any configurations on the system, only reports the active policy on the managed nodes.

2. Run the playbook on the same inventory file:

   # ansible-playbook -i inventory_file verify_playbook.yml
   
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   The "crypto_policies_active": variable shows the policy active 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
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. To enable authentication using a smart card on a remote server (example.com), transfer the public key to the remote server. Use the ssh-copy-id command with keys.pub created in the previous step:

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

3. To connect to example.com using the ECDSA key from the output of the ssh-keygen -D command in step 1, 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" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. 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 example.com
   Enter PIN for 'SSH key':
   [example.com] $

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

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

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. To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system, copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or /etc/pki/ca-trust/source/anchors/ directory, for example:

   # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/

2. To update the system-wide trust store configuration, use the update-ca-trust command:

   # update-ca-trust

Procedure

1. Use the oscap command with the --remediate option:

   $ sudo oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. Restart your system.

Verification

1. Evaluate compliance of the system with the HIPAA profile, and save scan results in the hipaa_report.html file:

   $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Procedure

1. Remediate your system to align with HIPAA using Ansible:

   # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-hipaa.yml

2. Restart the system.

Verification

1. Evaluate compliance of the system with the HIPAA profile, and save scan results in the hipaa_report.html file:

   # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Procedure

1. Scan the system and save the results:

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. Generate an Ansible playbook based on the file generated in the previous step:

   # oscap xccdf generate fix --fix-type ansible --profile hipaa --output hipaa-remediations.yml hipaa-results.xml

3. The hipaa-remediations.yml file contains Ansible remediations for rules that failed during the scan performed in step 1. After reviewing this generated file, you can apply it with the ansible-playbook hipaa-remediations.yml command.

Procedure

1. Use the oscap command to scan the system and to save the results to an XML file. In the following example, oscap evaluates the system against the hipaa profile:

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. Generate a Bash script based on the results file generated in the previous step:

   # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml

3. The hipaa-remediations.sh file contains remediations for rules that failed during the scan performed in step 1. After reviewing this generated file, you can apply it with the ./hipaa-remediations.sh command when you are in the same directory as this file.

Procedure

1. Download the latest RHSA OVAL definitions for your system:

   # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml

2. Get the ID of a container or a container image, for example:

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

3. Scan the container or the container image for vulnerabilities and save results to the vulnerability.html file:

   # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-9.oval.xml

   Note that the oscap-podman command requires root privileges, and the ID of a container is the first argument.

Procedure

1. Get the ID of a container or a container image, for example:

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB

2. Evaluate the compliance of the container image with the HIPAA profile and save scan results into the report.html HTML file

   # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   Replace 096cae65a207 with the ID of your container image and the hipaa value with ospp or pci-dss if you assess security compliance with the OSPP or PCI-DSS baseline. Note that the oscap-podman command requires root privileges.

Procedure

1. To install the aide package:

   # dnf install aide

2. To generate an initial database:

   # aide --init

   Note

   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.

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

4. 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: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
   AIDE found differences between database and filesystem!!
   ...
   [trimmed for clarity]

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. 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. Unmount all file systems on the device that you plan to encrypt. For example:

   # umount /dev/sdb1

2. Make free space for storing a LUKS header. Choose one of the following options that suits your scenario:

   • In the case of encrypting a logical volume, you can extend the logical volume without resizing the file system. For example:

     # lvextend -L+32M vg00/lv00

   • Extend the partition using partition management tools, such as parted.
   • Shrink the file system on the device. You can use the resize2fs utility for the ext2, ext3, or ext4 file systems. Note that you cannot shrink the XFS file system.

3. Initialize the encryption. For example:

   # cryptsetup reencrypt \
                --encrypt \
                --init-only \
                --reduce-device-size 32M \
                /dev/sdb1 sdb1_encrypted

   The command asks you for a passphrase and starts the encryption process.

4. Mount the device:

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

5. Start the online encryption:

   # cryptsetup reencrypt --resume-only /dev/sdb1

Procedure

1. Unmount all file systems on the device. For example:

   # umount /dev/sdb1

2. Initialize the encryption:

   # cryptsetup reencrypt \
                --encrypt \
                --init-only \
                --header /path/to/header \
                /dev/sdb1 sdb1_encrypted

   Replace /path/to/header with a path to the file with a detached LUKS header. The detached LUKS header has to be accessible so that the encrypted device can be unlocked later.

   The command asks you for a passphrase and starts the encryption process.

3. Mount the device:

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

4. Start the online encryption:

   # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

Procedure

1. Setup a partition as an encrypted LUKS partition:

   # cryptsetup luksFormat /dev/sdb1

2. Open an encrypted LUKS partition:

   # cryptsetup open /dev/sdb1 sdb1_encrypted

   This unlocks the partition and maps it to a new device using the device mapper. This alerts kernel that device is an encrypted device and should be addressed through LUKS using the /dev/mapper/device_mapped_name so as not to overwrite the encrypted data.

3. To write encrypted data to the partition, it must be accessed through the device mapped name. To do this, you must create a file system. For example:

   # mkfs -t ext4 /dev/mapper/sdb1_encrypted

4. Mount the device:

   # mount /dev/mapper/sdb1_encrypted mount-point

Procedure

1. Create a new playbook.yml file with the following content:

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

2. Optional: Verify playbook syntax:

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procedure

1. To install Clevis and its pins on a system with an encrypted volume:

   # dnf install clevis

2. To decrypt data, use a clevis decrypt command and provide a cipher text in the JSON Web Encryption (JWE) format, for example:

   $ clevis decrypt < secret.jwe

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

   Save the file and exit the editor.

7. Reload the changed configuration:

   # systemctl daemon-reload

8. Check that your configuration is working:

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

9. 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. Open the RHEL web console by entering the following address in a web browser:

   https://localhost:9090

   Replace the localhost part by the remote server’s host name or IP address when you connect to a remote system.

2. Provide your credentials and click Storage. Click > to expand details of the encrypted device you want to unlock using the Tang server, and click Encryption.

3. Click + in the Keys section to add a Tang key:

   

4. 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
   fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM

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

   

7. To enable the early boot system to process the disk binding, click Terminal at the bottom of the left navigation bar and enter the following commands:

   # dnf install clevis-dracut
   # grubby --update-kernel=ALL --args="rd.neednet=1"
   # dracut -fv --regenerate-all

8. To enable Clevis to unlock also volumes that mount late in the boot process, use the following command on the client before restarting the system:

   # systemctl enable clevis-luks-askpass.path

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
   clevis
   clevis-pin-sss
   clevis-pin-tang
   clevis-pin-tpm2
   -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
   -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
   ...
   -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
   -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

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 there is at least one free LUKS password slot. The clevis luks bind command takes one of the slots.

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

4. To enable Clevis to unlock also volumes that mount late in the boot process, use the following command on the client before restarting the system:

   # systemctl enable clevis-luks-askpass.path

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

   In RHEL, Clevis produces a generic initrd (initial ramdisk) 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:

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

   Alternatively, create a .conf file in the /etc/dracut.conf.d/, and add the hostonly_cmdline=yes option to the file, for example:

   # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf

   Note

   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"

   Then you can use dracut without --hostonly-cmdline:

   # 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: tang '{"url":"http://tang.srv:port"}'

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"}'

      Warning

      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. Optionally, 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 manual enrollment of LUKS-encrypted volumes.

   Note that the -y option for the clevis luks bind command is available from RHEL 8.3. In RHEL 8.2 and older, replace -y by -f in the clevis luks bind command and download the advertisement from the Tang server:

   %post
   curl -sfg http://tang.srv/adv -o adv.jws
   clevis luks bind -f -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv","adv":"adv.jws"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   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 manual enrollment 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/rhel9/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/rhel9/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/rhel9/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. Prepare your playbook containing settings for Tang servers. You can either start from the scratch, or use one of the example playbooks from the /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ directory.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

2. Edit the playbook in a text editor of your choice, for example:

   # vi my-tang-playbook.yml

3. Add the required parameters. The following example playbook ensures deploying of your Tang server and a key rotation:

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
   
     roles:
       - rhel-system-roles.nbde_server

4. Apply the finished playbook:

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   Where: * inventory-file is the inventory file. * logging-playbook.yml is the playbook you use.

Procedure

1. Prepare your playbook containing settings for Clevis clients. You can either start from the scratch, or use one of the example playbooks from the /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ directory.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

2. Edit the playbook in a text editor of your choice, for example:

   # vi my-clevis-playbook.yml

3. Add the required parameters. The following example playbook configures Clevis clients for automated unlocking of two LUKS-encrypted volumes by when at least one of two Tang servers is available:

   ---
   - hosts: all
   
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
   
     roles:
       - rhel-system-roles.nbde_client

4. Apply the finished playbook:

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

File-system rules examples

1. To define a rule that logs all write access to, and every attribute change of, the /etc/passwd file:

   # auditctl -w /etc/passwd -p wa -k passwd_changes

2. To define a rule that logs all write access to, and every attribute change of, all the files in the /etc/selinux/ directory:

   # auditctl -w /etc/selinux/ -p wa -k selinux_changes

System-call rules examples

1. To define a rule that creates a log entry every time the adjtimex or settimeofday system calls are used by a program, and the system uses the 64-bit architecture:

   # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

2. To define a rule that creates a log entry every time a file is deleted or renamed by a system user whose ID is 1000 or larger:

   # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

   Note that the -F auid!=4294967295 option is used to exclude users whose login UID is not set.

Procedure

1. Copy the /usr/lib/systemd/system/auditd.service file to the /etc/systemd/system/ directory:

   # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/

2. Edit the /etc/systemd/system/auditd.service file in a text editor of your choice, for example:

   # vi /etc/systemd/system/auditd.service

3. Comment out the line containing augenrules, and uncomment the line containing the auditctl -R command:

   #ExecStartPost=-/sbin/augenrules --load
   ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules

4. Reload the systemd daemon to fetch changes in the auditd.service file:

   # systemctl daemon-reload

5. Restart the auditd service:

   # service auditd restart

Procedure

1. Copy the pre-configured rule file 44-installers.rules from the /usr/share/audit/sample-rules/ directory to the /etc/audit/rules.d/ directory:

   # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/

2. Load the audit rules:

   # augenrules --load

Verification

1. List the loaded rules:

   # auditctl -l
   -p x-w /usr/bin/dnf-3 -k software-installer
   -p x-w /usr/bin/yum -k software-installer
   -p x-w /usr/bin/pip -k software-installer
   -p x-w /usr/bin/npm -k software-installer
   -p x-w /usr/bin/cpan -k software-installer
   -p x-w /usr/bin/gem -k software-installer
   -p x-w /usr/bin/luarocks -k software-installer

2. Perform an installation, for example:

   # dnf reinstall -y vim-enhanced

3. Search the Audit log for recent installation events, for example:

   # ausearch -ts recent -k software-installer
   ––––
   time->Thu Dec 16 10:33:46 2021
   type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
   type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=CWD msg=audit(1639668826.074:298): cwd="/root"
   type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
   type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

Procedure

1. Install the fapolicyd package:

   # dnf install fapolicyd

2. Enable and start the fapolicyd service:

   # systemctl enable --now 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; vendor p>
      Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
     Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
    Main PID: 8819 (fapolicyd)
       Tasks: 4 (limit: 11500)
      Memory: 78.2M
      CGroup: /system.slice/fapolicyd.service
              └─8819 /usr/sbin/fapolicyd
   
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
   Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database

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.

3. Update the fapolicyd database:

   # fapolicyd-cli --update

4. Restart fapolicyd:

   # systemctl restart fapolicyd

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/ all trust=0

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. Install the usbguard package:

   # dnf install usbguard

2. Create an initial rule set:

   # usbguard generate-policy > /etc/usbguard/rules.conf

3. Start the usbguard daemon and ensure that it starts automatically on boot:

   # systemctl enable --now usbguard

Verification

1. Verify that the usbguard service is running:

   # systemctl status usbguard
   ● usbguard.service - USBGuard daemon
      Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled)
      Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago
        Docs: man:usbguard-daemon(8)
    Main PID: 6122 (usbguard-daemon)
       Tasks: 3 (limit: 11493)
      Memory: 1.2M
      CGroup: /system.slice/usbguard.service
              └─6122 /usr/sbin/usbguard-daemon -f -s -c /etc/usbguard/usbguard-daemon.conf
   
   Nov 07 09:44:06 localhost.localdomain systemd[1]: Starting USBGuard daemon...
   Nov 07 09:44:07 localhost.localdomain systemd[1]: Started USBGuard daemon.

2. List USB devices recognized by USBGuard:

   # usbguard list-devices
   4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...

Procedure

1. List USB devices recognized by USBGuard:

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

2. Authorize the device 6 to interact with the system:

   # usbguard allow-device 6

3. Deauthorize and remove the device 6:

   # usbguard reject-device 6

4. Deauthorize and retain the device 6:

   # usbguard block-device 6

Procedure

1. Configure SELinux to allow the usbguard daemon to write rules.

   1. Display the semanage Booleans relevant to usbguard.

      # semanage boolean -l | grep usbguard
      usbguard_daemon_write_conf     (off  ,  off)  Allow usbguard to daemon write conf
      usbguard_daemon_write_rules    (on   ,   on)  Allow usbguard to daemon write rules

   2. Optional: If the usbguard_daemon_write_rules Boolean is turned off, turn it on.

      # semanage boolean -m --on usbguard_daemon_write_rules

2. List USB devices recognized by USBGuard:

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

3. Permanently authorize the device 6 to interact with the system:

   # usbguard allow-device 6 -p

4. Permanently deauthorize and remove the device 6:

   # usbguard reject-device 6 -p

5. Permanently deauthorize and retain the device 6:

   # usbguard block-device 6 -p

Verification

1. Check that USBGuard rules include the changes you made.

   # usbguard list-rules

Procedure

1. Create a policy which authorizes the currently connected USB devices, and store the generated rules to the rules.conf file:

   # usbguard generate-policy --no-hashes > ./rules.conf

   The --no-hashes option does not generate hash attributes for devices. Avoid hash attributes in your configuration settings because they might not be persistent.

2. Edit the rules.conf file with a text editor of your choice, for example:

   # vi ./rules.conf

3. Add, remove, or edit the rules as required. For example, the following rule allows only devices with a single mass storage interface to interact with the system:

   allow with-interface equals { 08:*:* }

   See the usbguard-rules.conf(5) man page for a detailed rule-language description and more examples.

4. Install the updated policy:

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

5. Restart the usbguard daemon to apply your changes:

   # systemctl restart usbguard

Verification

1. Check that your custom rules are in the active policy, for example:

   # usbguard list-rules
   ...
   4: allow with-interface 08:*:*
   ...

Procedure

1. Create a policy which authorizes the currently connected USB devices, and store the generated rules to a new .conf file, for example, policy.conf.

   # usbguard generate-policy --no-hashes > ./policy.conf

   The --no-hashes option does not generate hash attributes for devices. Avoid hash attributes in your configuration settings because they might not be persistent.

2. Display the policy.conf file with a text editor of your choice, for example:

   # vi ./policy.conf
   ...
   allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

3. Move selected lines into a separate .conf file.

   Note

   The two digits at the beginning of the file name specify the order in which the daemon reads the configuration files.

   For example, copy the rules for your keyboards into a new .conf file.

   # grep "USB Keyboard" ./policy.conf > ./10keyboards.conf

4. Install the new policy to the /etc/usbguard/rules.d/ directory.

   # install -m 0600 -o root -g root 10keyboards.conf /etc/usbguard/rules.d/10keyboards.conf

5. Move the rest of the lines to a main rules.conf file.

   # grep -v "USB Keyboard" ./policy.conf > ./rules.conf

6. Install the remaining rules.

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

7. Restart the usbguard daemon to apply your changes.

   # systemctl restart usbguard

Verification

1. Display all active USBGuard rules.

   # usbguard list-rules
   ...
   15: allow id 04f2:0833 serial "" name "USB Keyboard" hash "kxM/iddRe/WSCocgiuQlVs6Dn0VEza7KiHoDeTz0fyg=" parent-hash "2i6ZBJfTl5BakXF7Gba84/Cp1gslnNc1DM6vWQpie3s=" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

2. Display the contents of the rules.conf file and all the .conf files in the /etc/usbguard/rules.d/ directory.

   # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf

3. Verify that the active rules contain all the rules from the files and are in the correct order.

Procedure

1. Edit the /etc/usbguard/usbguard-daemon.conf file with a text editor of your choice:

   # vi /etc/usbguard/usbguard-daemon.conf

2. For example, add a line with a rule that allows all users in the wheel group to use the IPC interface, and save the file:

   IPCAllowGroups=wheel

3. You can add users or groups also with the usbguard command. For example, the following command enables the joesec user to have full access to the Devices and Exceptions sections. Furthermore, joesec can list and modify the current policy:

   # usbguard add-user joesec --devices ALL --policy modify,list --exceptions ALL

   To remove the granted permissions for the joesec user, use the usbguard remove-user joesec command.

4. Restart the usbguard daemon to apply your changes:

   # systemctl restart usbguard

Procedure

1. Edit the usbguard-daemon.conf file with a text editor of your choice:

   # vi /etc/usbguard/usbguard-daemon.conf

2. Change the AuditBackend option from FileAudit to LinuxAudit:

   AuditBackend=LinuxAudit

3. Restart the usbguard daemon to apply the configuration change:

   # systemctl restart usbguard

Verification

1. Query the audit daemon log for a USB authorization event, for example:

   # ausearch -ts recent -m USER_DEVICE

Procedure

1. Optional: To use a different port for rsyslog traffic, add the syslogd_port_t SELinux type to port. For example, enable port 30514:

   # semanage port -a -t syslogd_port_t -p tcp 30514

2. Optional: To use a different port for rsyslog traffic, configure firewalld to allow incoming rsyslog traffic on that port. For example, allow TCP traffic on port 30514:

   # firewall-cmd --zone=<zone-name> --permanent --add-port=30514/tcp
   success
   # firewall-cmd --reload

3. Create a new file in the /etc/rsyslog.d/ directory named, for example, remotelog.conf, and insert the following content:

   # Define templates before the rules that use them
   # Per-Host templates for remote systems
   template(name="TmplAuthpriv" type="list") {
       constant(value="/var/log/remote/auth/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   template(name="TmplMsg" type="list") {
       constant(value="/var/log/remote/msg/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   # Provides TCP syslog reception
   module(load="imtcp")
   
   # Adding this ruleset to process remote messages
   ruleset(name="remote1"){
        authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
         *.info;mail.none;authpriv.none;cron.none
   action(type="omfile" DynaFile="TmplMsg")
   }
   
   input(type="imtcp" port="30514" ruleset="remote1")

4. Save the changes to the /etc/rsyslog.d/remotelog.conf file.

5. Test the syntax of the /etc/rsyslog.conf file:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

6. Make sure the rsyslog service is running and enabled on the logging server:

   # systemctl status rsyslog

7. Restart the rsyslog service.

   # systemctl restart rsyslog

8. Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

   # systemctl enable rsyslog

Procedure

1. Create a new file in the /etc/rsyslog.d/ directory named, for example, 10-remotelog.conf, and insert the following content:

   *.* action(type="omfwd"
         queue.type="linkedlist"
         queue.filename="example_fwd"
         action.resumeRetryCount="-1"
         queue.saveOnShutdown="on"
         target="example.com" port="30514" protocol="tcp"
        )

   Where:

   • queue.type="linkedlist" enables a LinkedList in-memory queue,
   • queue.filename defines a disk storage. The backup files are created with the example_fwd prefix in the working directory specified by the preceding global workDirectory directive,
   • the action.resumeRetryCount -1 setting prevents rsyslog from dropping messages when retrying to connect if server is not responding,
   • enabled queue.saveOnShutdown="on" saves in-memory data if rsyslog shuts down,

   • the last line forwards all received messages to the logging server, port specification is optional.

     With this configuration, rsyslog sends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance.

   Note

   Rsyslog processes configuration files /etc/rsyslog.d/ in the lexical order.

2. Restart the rsyslog service.

   # systemctl restart rsyslog

1. On the client system, send a test message:

   # logger test

2. On the server system, view the /var/log/messages log, for example:

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Procedure

1. Configure the server for receiving encrypted logs from your client systems:

   1. Create a new file in the /etc/rsyslog.d/ directory named, for example, securelogser.conf.

   2. To encrypt the communication, the configuration file must contain paths to certificate files on your server, a selected authentication method, and a stream driver that supports TLS encryption. Add the following lines to the /etc/rsyslog.d/securelogser.conf file:

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/server-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/server-key.pem"
      )
      
      # TCP listener
      module(
        load="imtcp"
        PermittedPeer=["client1.example.com", "client2.example.com"]
        StreamDriver.AuthMode="x509/name"
        StreamDriver.Mode="1"
        StreamDriver.Name="ossl"
      )
      
      # Start up listener at port 514
      input(
        type="imtcp"
        port="514"
      )

      Note

      If you prefer the GnuTLS driver, use the StreamDriver.Name="gtls" configuration option. See the documentation installed with the rsyslog-doc package for more information about less strict authentication modes than x509/name.

   3. Save the changes to the /etc/rsyslog.d/securelogser.conf file.

   4. Verify the syntax of the /etc/rsyslog.conf file and any files in the /etc/rsyslog.d/ directory:

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.

   5. Make sure the rsyslog service is running and enabled on the logging server:

      # systemctl status rsyslog

   6. Restart the rsyslog service:

      # systemctl restart rsyslog

   7. Optional: If Rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

      # systemctl enable rsyslog

2. Configure clients for sending encrypted logs to the server:

   1. On a client system, create a new file in the /etc/rsyslog.d/ directory named, for example, securelogcli.conf.

   2. Add the following lines to the /etc/rsyslog.d/securelogcli.conf file:

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/client-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/client-key.pem"
      )
      
      
      # Set up the action for all messages
      *.* action(
        type="omfwd"
        StreamDriver="ossl"
        StreamDriverMode="1"
        StreamDriverPermittedPeers="server.example.com"
        StreamDriverAuthMode="x509/name"
        target="server.example.com" port="514" protocol="tcp"
      )

      Note

      If you prefer the GnuTLS driver, use the StreamDriver.Name="gtls" configuration option.

   3. Save the changes to the /etc/rsyslog.d/securelogser.conf file.

   4. Verify the syntax of the `/etc/rsyslog.conf file and other files in the /etc/rsyslog.d/ directory:

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.

   5. Make sure the rsyslog service is running and enabled on the logging server:

      # systemctl status rsyslog

   6. Restart the rsyslog service:

      # systemctl restart rsyslog

   7. Optional: If Rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

      # systemctl enable rsyslog

1. On the client system, send a test message:

   # logger test

2. On the server system, view the /var/log/messages log, for example:

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Procedure

1. Optional: To use a different port for rsyslog traffic than the default port 514:

   1. Add the syslogd_port_t SELinux type to the SELinux policy configuration, replacing portno with the port number you want rsyslog to use:

      # semanage port -a -t syslogd_port_t -p udp portno

   2. Configure firewalld to allow incoming rsyslog traffic, replacing portno with the port number and zone with the zone you want rsyslog to use:

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
      # firewall-cmd --reload

   3. Reload the firewall rules:

      # firewall-cmd --reload

2. Create a new .conf file in the /etc/rsyslog.d/ directory, for example, remotelogserv.conf, and insert the following content:

   # Define templates before the rules that use them
   # Per-Host templates for remote systems
   template(name="TmplAuthpriv" type="list") {
       constant(value="/var/log/remote/auth/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   template(name="TmplMsg" type="list") {
       constant(value="/var/log/remote/msg/")
       property(name="hostname")
       constant(value="/")
       property(name="programname" SecurePath="replace")
       constant(value=".log")
       }
   
   # Provides UDP syslog reception
   module(load="imudp")
   
   # This ruleset processes remote messages
   ruleset(name="remote1"){
        authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
         *.info;mail.none;authpriv.none;cron.none
   action(type="omfile" DynaFile="TmplMsg")
   }
   
   input(type="imudp" port="514" ruleset="remote1")

   Where 514 is the port number rsyslog uses by default. You can specify a different port instead.

3. Verify the syntax of the /etc/rsyslog.conf file and all .conf files in the /etc/rsyslog.d/ directory:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

4. Restart the rsyslog service.

   # systemctl restart rsyslog

5. Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

   # systemctl enable rsyslog

Procedure

1. Create a new .conf file in the /etc/rsyslog.d/ directory, for example, 10-remotelogcli.conf, and insert the following content:

   *.* action(type="omfwd"
         queue.type="linkedlist"
         queue.filename="example_fwd"
         action.resumeRetryCount="-1"
         queue.saveOnShutdown="on"
         target="example.com" port="portno" protocol="udp"
        )

   Where:

   • queue.type="linkedlist" enables a LinkedList in-memory queue.
   • queue.filename defines a disk storage. The backup files are created with the example_fwd prefix in the working directory specified by the preceding global workDirectory directive.
   • The action.resumeRetryCount -1 setting prevents rsyslog from dropping messages when retrying to connect if the server is not responding.
   • enabled queue.saveOnShutdown="on" saves in-memory data if rsyslog shuts down.
   • portno is the port number you want rsyslog to use. The default value is 514.

   • The last line forwards all received messages to the logging server, port specification is optional.

     With this configuration, rsyslog sends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance.

   Note

   Rsyslog processes configuration files /etc/rsyslog.d/ in the lexical order.

2. Restart the rsyslog service.

   # systemctl restart rsyslog

3. Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

   # systemctl enable rsyslog

1. On the client system, send a test message:

   # logger test

2. On the server system, view the /var/log/remote/msg/hostname/root.log log, for example:

   # cat /var/log/remote/msg/hostname/root.log
   Feb 25 03:53:17 hostname root[6064]: test

   Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.