Installing on Fedora 42 

Fedora 42 and Systemd/UKI - A status Update

Fedora 42 offers some significant additions to Trusted Booting. Most notably it adds an optional plugin to rpm that automatically adds Fedora signatures to all files for IMA measurement and appraisal. This is a huge improvement not only for supporting local IMA appraisal, but also for supporting the remote verification of TPM based attestation. Now IMA measurement with the ima-sig template will include a file's hash and a Fedora signature on that hash in each measurement event. The verifier can easily verify that all measured files are authentic Fedora files, by verifying their signatures with the Fedora public certificate. These signatures are updated automatically with dnf updates and upgrades.

Taken together with the previously available Trusted Boot enhancements, and some additional optional packages, a Fedora system now can have:

• Secure boot of a signed UKI kernel+initrd+cmdline  

  • no more appraisal gap in the initrd

  • enhanced measurements in PCRs 11 and 15 

• Simplified Management of all secure boot keys

• Measurement, appraisal, and attestation of all files signed by Fedora

• Use of the TPM to unlock all encrypted partitions at boot

• TPM provisioning for backup and restore of all stored keys across TPM failure
  
  

    Important Update: These instructions have been extended to turn on IMA Appraisal
    in addition to the original IMA Measurement and Attestation.

Comments on Booting

The new UKI kernel cannot be booted from Grub.

It can be booted from:

sdboot (This was how the version on Fedora 39 was booted)

 UEFI Boot Menu

 shim

Booting from sdboot is convenient, as it has shim support for Fedora signed uki, and it has an attractive menu at boot. It is, however the hardest to install, as shown in the Fedora 39 instructions.

Booting from the UEFI boot menu is a little less friendly - you have to remember which key to press to get the boot menu, and have to time it well at boot time. In addition, the UEFI does not support Fedora's signature keys. If you want to sign your own UKI, you have to add the keys to the UEFI db.

Fedora 40 boots the UKI directly from the shim. The shim has been extended to look at its UEFI boot variable, where the target UKI file path has been appended. Fedora 40 added a utility "kernel-bootcfg" as a friendly front end to the underlying efibootmgr. Booting from the shim is convenient, as it supports Fedora's keys, and it is already installed. As with booting directly from the UEFI menu, it is tricky to get the UEFI boot menu if you want to boot something other than the default.

In a little more detail, here is a Fedora UEFI boot variable for a UKI, dumped with efibootmgr:

      Boot0003*
Fedora 42 UKI HD(1,GPT,9158a8bd-c340-48c3-a4f1-9dae2c5bb862,0x800,0x1eb800)/
      \EFI\fedora\shimx64.efi
5c004500460049005c004c0069006e00750078005c0076006d006c0069006e
0075007a002d0036002e00310034002e00310031002d003300300030002e00
66006300340032002e007800380036005f00360034002e007300690067006e
00650064002e006500660069000000

The first two lines are the title, device, and path to the efi executable to be run by UEFI.

The  part after the .efi path is the path to the UKI in unicode.  Translated this is:

\EFI\Linux\vmlinuz-6.14.11-300.fc42.x86_64.signed.efi

The fedora shim knows to look for this path for a UKI to boot. If it does not find a UKI, it will try to boot grub. Note that that this means the UKI file must be in the EFI System partition, not the boot partition, so plan partition sizes accordingly.

Comments on Keyrings and Key Management

Secureboot, LUKS partition encryption, and IMA appraisal depend on a number of keys. These keys are stored and managed in a number of locations, and can be used in only certain ways, which can be a bit confusing. Keys can be stored in:

• UEFI secure boot storage hierarchy of PK, KEK, and DB

• MOK keys, maintained by the boot shim, IF SECURE BOOT is enabled

• Keys built into the kernel

• Keys loaded into the kernel from the initrd

• Keys in the TPM

• LUKS keys stored in a partition header
  
  

In Linux keys are loaded onto keyrings for use. These keyrings include:

.platform (UEFI DB keys)

.machine (MOK keys loaded by the SHIM, including IMA-CA keys)

.ima (IMA appraisal public key certificates, which must be signed by IMA-CA key)

With secureboot enabled, UEFI will not load the first efi executable unless it is signed by a key whose public key certificate is in the UEFI DB. Most commercial systems ship with Microsoft and OEM keys in the DB. Linux distributions did not want users to have to add keys to the DB, so they created a shim that is signed by Microsoft, and which maintains a MOK list of keys needed to boot the Linux distribution. As the kernel boots, it loads the UEFI keys into the .platform keyring, and the MOK keys into the .machine keyring. Keys used by IMA to appraise the signatures on files are loaded onto the .ima keyring by code in the initrd. These IMA keys cannot be loaded unless they are signed by a CA key which is already loaded on the .machine keyring. With secureboot enabled, if you want to load a new IMA policy file (and we do), it must also be signed by a key on the .ima keyring.

So to summarize, we have to boot the SHIM, to be able to load an IMA-CA key, so that we can load an IMA appraisal key on the .ima keyring. Since the SHIM is signed by Microsoft, we don't have to add any keys to the DB, although for tightest security we may want to remove unneeded keys from the DB. This is strictly optional, but will be shown in the following detailed installation instructions.

As an example, here is the .platform keyring (basically the UEFI DB) for my desktop:

root@fedora:~# keyctl show %:.platform

Keyring

  974482125 ---lswrv      0     0  keyring: .platform
  906701518 ---lswrv      0     0   \_ asymmetric: MSI SHIP DB: ebc30d5be5f35f8041c1c2d9e613eee2
  373368820 ---lswrv      0     0   \_ asymmetric: Red Hat, Inc.: fedoraca: b280c7ae6b884e0f4d2a0d8724c25eaf6c65c326
  27530299 ---lswrv       0     0   \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
  349870059 ---lswrv      0     0   \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4

Here are the keyrings that result from installing Fedora 42 according to the following instructions:

root@fedora:~# keyctl show %:.platform

Keyring

  39127028 ---lswrv       0     0  keyring: .platform
  568656572 ---lswrv      0     0   \_ asymmetric: Database Key: 4ad183226cb3782590ba640dcc64b71d
  848605927 ---lswrv      0     0   \_ asymmetric: Red Hat, Inc.: fedoraca: b280c7ae6b884e0f4d2a0d8724c25eaf6c65c326

root@fedora:~# keyctl show %:.machine

Keyring

  979512042 ---lswrv      0     0  keyring: .machine
  208043151 ---lswrv      0     0   \_ asymmetric: Fedora IMA CA: a8a00c31663f853f9c6ff2564872e378af026b28
  256133155 ---lswrv      0     0   \_ asymmetric: IMA-CA: IMA/EVM certificate signing key: 053d15b3dc9cd8037c279f312c15d1898907ddfa

root@fedora:~# keyctl show %:.ima

Keyring

  103441207 ---lswrv      0     0  keyring: .ima
  481320317 ---lswrv      0     0   \_ asymmetric: Fedora kernel signing key: bdd97e5f021e87305c0853e144d02b0c516919d4
  6610314 --als--v        0     0   \_ asymmetric: fedora: dave signing key: 7acd5d5e0e6765c2aa7aea8e4c4af1e1174f5c3b
  155080207 --als--v      0     0   \_ asymmetric: Fedora 42 IMA Code-signing cert: a1a5c4c8d90554e0ce5c07c9e127f20362f02aa4
  576236972 --als--v      0     0   \_ asymmetric: Fedora 41 IMA Code-signing cert: 158befb98fc2ee070833d1a2a46669e7876d7435
  114564040 --als--v      0     0   \_ asymmetric: Fedora 40 IMA Code-signing cert: 2defa2e1d528db308d3e1ca28274aa40a3204a9e
  30695816 --als--v       0     0   \_ asymmetric: Fedora 39 IMA Code-signing cert: 155266a4a3ea7bdddc9e38ddb192c2d2388b603e

Note that the .platform keyring (from UEFI) no longer has any Microsoft keys, but does have a Red Hat key, and a local key.

The .platform keyring (from the SHIM's MOK) has Fedora CA and local CA keys.

The .ima keyring has several Fedora appraisal keys, and one local (dave) signing key, so that I can sign and load a new IMA policy. (more about that later).

Comments on IMA Measurement vs IMA Appraisal of Fedora Signed Packages

Fedora packages now come with digital signatures on all files, and if IMA Measurement is enabled these signatures are recorded in the event log for verification by the third party attestation verifier. If IMA Appraisal is also enabled, the local host verifies the signature, and blocks access/execution if there is no signature, or the signature is invalid. A problem can occur if a package installation creates new executable scripts as part of the installation, as created scripts will not be signed. It's considered bad practice for a package to create such scripts during installation, but unfortunately many packages still do so. For this reason, these instructions turn off automatic updates. 

Comments on Verification of the Event Log:

Most notably Fedora 42 adds Fedora signatures to all files installed from an RPM. For attestation this is huge. Even if you don't want to enable IMA apprasial, simply turning on IMA measurement with the ima-sig template causes every event log entry to contain a files hash and Fedora signature. If the event log is sent to a remote verifier, all it needs to verify the files as authentic, untampered Fedora files is to verify the signatures with the Fedora signature public key certificate. The following instructions show how to enable this attestation with the kernel command line options "ima_template=ima-sig" and "ima_policy=tcb".

Fedora 40 has also significantly extended the measurement system. Most importantly it has added the measurement of the root partition ID and volume key to PCR-15. Because the event log does not contain the secret volume key, there is no way for the verifier to verify the digest for this event - the verifier can only tell if it has changed or not. In addition, the verifier needs the digest that was extended for this event, as it cannot calculate it from the event content. In earlier versions of systemd, the events were logged in journald, and did not contain the digests.

Fortunately systemd version 255 in Fedora 40 adds an explicit event log in the file /run/log/systemd/tpm2-measure.log. This file is in json format, and is easily converted to CEL format for verification. With this new log, it is possible to verify the overall events for PCR-15, although it is still not possible to verify the event contents for the root/volume key event.

Note that there is currently (as of 5/27/2024) still a bug in the selinux policy that blocks the creation of the tpm2-measure.log. The cel_utils that are installed are able to extract the systemd events from either this log, or from systgemd's journal.

Detailed Installation Instructions

These instructions are for installation in a virt-manager VM running on a current Fedora. You should be able to install it on other systems or even on bare metal, but that has not yet been tested.

In the instructions, a '$' prompt indicates the command is run as a user. If
the prompt is '#', it is run as root. You can get a root shell by running  "sudo -i".

Note that these instructions involve rebooting frequently. Normally the installation would be fully scripted with anaconda, requiring only one reboot. Here we reboot frequently as a way of testing each step, so that we can test and discover any problems quickly.

I. Install the base Fedora 42:

   a. Download Fedora 42 installation image. I used:  

      https://download.fedoraproject.org/pub/fedora/linux/releases/42/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso

   b. Create the VM with virt-manager. To create a VM:
    - Start virt-manager as a user:
        $ virt-manager 

   - Click the icon to create a new VM.

   - Select "local install media" (which should be the default), then click "forward".

   - Browse to find and select the Fedora Workstation Live iso you downloaded, and click "forward".

   - Set CPU parameters (I used 4096 RAM, 4 threads), and click "forward".

   - Set the disk size (I set 42GB), then click "forward".

   - In the "Create a new virtual machine" window, select 

      "Customize configuration before install", then click "Finish".

   - In the Installation window, first

      - set "Firmware" to "UEFI x86_64:/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2",
        and click "Apply".

      - Click the "Add Hardware" button.

      - In the "Add New Virtual Hardware" window, click on "TPM", then click "Finish"

      - Back in the Installation window, click on the "Begin Installation" button.

   c. Install Fedora in the VM:

   - The system will boot to the GUI installer. Run the installer as normal, except,
      in  the "Installation Method" screen, click on the top right corner menu (three dots),
      and click on "Launch Storage Editor":

         - In the "Storage Editor" window:

  - on the "vda" line click the menu, and "create partition table"
  - on the "free space" line click on the menu to create the needed partitions:
/boot/efi partition (1GB, unencrypted, type EFI)
/boot partition (1GB, unencrypted, type ext4)
/ partition (20GB, encrypted with LUKS2, ext4)
/opt partition (10 GB, encrypted with LUKS2, ext4)
/data partition (10 GB, encrypted with LUKS2, ext4)

         - Click "return to installation"

      - Click "Continue"

      - Click "next"

      - When installation is complete click "Reboot System" to reboot the VM.

        (Note you will be asked for the LUKS key during boot. We will fix this later.)

II. Install rpm-plugin-ima and add Fedora signatures to all files

First open the "Software" program (on the bottom panel), go to preferences
and turn off automatic updates. (We can turn this back on later, but we don't
want updates to come in the middle of this installation.)

Second, install the plugin and reinstall all packages to apply the Fedora signatures:

# dnf install rpm-plugin-ima
# dnf reinstall --skip-unavailable $(rpm -qa)
# dnf update

Add your user to the tss group:

  # usermod -a -G tss <username>

Reboot to run the latest kernel

Install some more needed packages for the latest kernel

      # dnf install ima-evm-utils
      # dnf install pesign sbsigntools kernel-devel-$(uname -r) golang asciidoc systemd-ukify
      # dnf install systemd-devel
      # dnf install tpm2-tss-devel
      # dnf install python3-virt-firmware
      # dnf install pcsc-lite-devel

    build and install sbctl
      $ cd
      $ git clone https://github.com/foxboron/sbctl.git
      $ cd sbctl
      $ make
      $ sudo make install   

    build and install cel_util

      $ cd
      $ git clone https://github.com/safforddr/cel_util.git
      $ cd cel_util
      $ make

Check that fedora-gpg-keys installed the Fedora IMA code signing keys and the IMA-CA key:

  $ ls /etc/keys/ima/
  $ ls /usr/share/ima/ca.der)

     Now we need to add our own local IMA signing key, so that we can sign a new policy:

        $ cd
        $ git clone https://github.com/linux-integrity/ima-evm-utils.git
        $ cd ima-evm-utils/examples
        $ ./ima-gen-local-ca.sh
        $ ./ima-genkey.sh
        $ sudo cp x509_ima.der /etc/keys/ima
        $ cp /etc/keys/ima/* ../../cel_util
        $ sudo mokutil --import ima-local-ca.x509

(mokutil will ask for a temporary password which you will
need to add the key when you reboot.)

     Reboot to add the key to MOK. 

     When you reboot, the shim will invoke the MOK key manager.
      Select the following menu entries

Enroll MOK
  Continue
  Yes
  (enter mokutil password)
  reboot

     After the reboot, check that the IMA-CA key has been added:

     # keyctl show %:.machine

    (Note that this will only work if you still have secure boot enabled.
      If you don't see the IMA-CA key on the machine key ring, double check that secureboot is enabled.)

    This should be the only entry on the machine (MOK) key ring.

    Next as root edit

        /lib/dracut/modules.d/97masterkey/module-setup.sh

        /lib/dracut/modules.d/98integrity/module-setup.sh

    In each file change the "return 255" to "return 0".

    Rebuild the initramfs.

        # dracut --kver $(uname -r) --force --add integrity

    reboot

    Use keyctl show to check the keyrings:

# keyctl show %:.platform
# keyctl show %:.machine
# keyctl show %:.ima

    The .machine key ring should have the new IMA-CA key, and the .ima
    keyring should have the local IMA signing key ("localhost-live: dave signing key",
    where "dave" is replaced with whatever username you used).  
        

III. Create and enroll our own sb keys, and sign grub and the traditional kernel:

   - reboot and press ESC repeatedly to enter UEFI setup mode, and force
      secure boot setup mode. (Note: if you miss the setup window, just wait for the grub menu, and select the "UEFI Firmware Settings" menu entry). Then:

      - Use arrows to select "Device Manager" and press Enter.

      - Select "Secure Boot Configuration" and press Enter.

      - Select "Reset Secure Boot Keys", and respond yes to confirm. This puts secure boot in "setup" mode.

      - Press F10 to save, and press ESC to return to the top menu.

      - Select "Continue" to boot to the Grub boot menu.      

   a. Log in the the booted VM 

   b. Create local UEFI keys (stored in /usr/share/secureboot): 

     # sbctl create-keys

     # sbctl enroll-keys --tpm-eventlog     

   c. Sign all the files

     run "sbctl verify" which will list all files that need to be signed.

     Sign all the files with sbctl sign --save <filename>  

   d. Check that everything is signed:

     # sbctl verify

       Verifying file database and EFI images in /boot/efi...

        ✓ /boot/efi/EFI/fedora/grubx64.efi is signed
        ✓ /boot/efi/EFI/fedora/mmx64.efi is signed
        ✓ /boot/efi/EFI/fedora/shim.efi is signed
        ✓ /boot/efi/EFI/fedora/shimx64.efi is signed
        ✓ /boot/efi/EFI/BOOT/BOOTX64.EFI is signed
        ✓ /boot/efi/EFI/BOOT/fbx64.efi is signed

   e. reboot 
          

IV. Provision TPM and enroll LUKS key

   a. check that secure boot is running correctly with the new keys:

       # sbctl status

       Installed: ✓ sbctl is installed
        Owner GUID: e3593590-f537-4f3f-b6e0-c37a10f2837f
        Setup Mode: ✓ Disabled
        Secure Boot: ✓ Enabled
        Vendor Keys: tpm-eventlog

   b. Set TPM owner password, and create a persistent SRK at 0x81000001:

      In the following command, replace <my_owner_password> with yours, and remember it.

      $ tpm2_changeauth -c owner <my_owner_password>
      $ echo "SRK" | tpm2_createprimary -c primary.ctx -P <my_owner_password> -u -
      $ tpm2_evictcontrol -C o -c primary.ctx 0x81000001 -P <my_owner_password>

   c. As root, enroll the LUKS key in the TPM for /, /opt, and /data:

      # systemd-cryptenroll /dev/vda3 --tpm2-device=auto --tpm2-seal-key-handle=0x81000001
      # systemd-cryptenroll /dev/vda4 --tpm2-device=auto --tpm2-seal-key-handle=0x81000001
      # systemd-cryptenroll /dev/vda5 --tpm2-device=auto --tpm2-seal-key-handle=0x81000001

   d. add ",tpm2-device=auto" to the end of the lines in /etc/crypttab

   e. Rebuild initrd

      # dracut -f --add integrity

   f. reboot

      This time, the encryption keys should be obtained from the TPM automatically!

V. Set new IMA policy and Fix IMA appraisal labels

At this point we are measuring everything, and saving the fedora signatures on all files in the Event Log for later attestation, but we are not using IMA Appraisal to enforce the signatures during run-time. To do that we have to first run ima_appraise=fix with secureboot turned off, and boot the system to make sure everything is properly labeled. (Everything installed from fedora rpms should have signatures, but many as described in an earlier "comment", some scripts are generated and installed, particularly by dracut, that are not signed.)

   a. reboot into UEFI, (pressing ESC as tianocore is booting) and turn off secure boot

   b. boot into the grub menu, and press 'e' to edit the kernel command line, adding "ima_appraise=fix ima_policy=appraise_tcb"

   c. continue the boot, so that everything gets labeled properly

   a. As root, cd to the ima-evm-utils/examples directory (where the local IMA keys were generated)

    # vi /etc/sysconfig/ima-policy to contain the lines:

dont_measure fsmagic=0x9fa0          # PROC_SUPER_MAGIC
dont_measure fsmagic=0x62656572      # SYSFS_MAGIC
dont_measure fsmagic=0x64626720      # DEBUGFS_MAGIC
dont_measure fsmagic=0x1021994       # TMPFS_MAGIC
dont_measure fsmagic=0x1cd1          # DEVPTS_SUPER_MAGIC
dont_measure fsmagic=0x42494e4d      # BINFMTFS_MAGIC
dont_measure fsmagic=0x73636673      # SECURITYFS_MAGIC
dont_measure fsmagic=0xf97cff8c      # SELINUX_MAGIC
dont_measure fsmagic=0x43415d53      # SMACK_MAGIC
dont_measure fsmagic=0x27e0eb        # CGROUP_SUPER_MAGIC
dont_measure fsmagic=0x63677270      # CGROUP2_SUPER_MAGIC
dont_measure fsmagic=0x6e736673      # NSFS_MAGIC
dont_measure fsmagic=0xde5e81e4      # EFIVARFS_MAGIC
measure func=MMAP_CHECK mask=MAY_EXEC
measure func=BPRM_CHECK mask=MAY_EXEC           # binary executed
measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
measure func=POLICY_CHECK
dont_appraise fsmagic=0x9fa0         # PROC_SUPER_MAGIC
dont_appraise fsmagic=0x62656572     # SYSFS_MAGIC
dont_appraise fsmagic=0x64626720     # DEBUGFS_MAGIC
dont_appraise fsmagic=0x1021994      # TMPFS_MAGIC
dont_appraise fsmagic=0x858458f6     # RAMFS_MAGIC
dont_appraise fsmagic=0x1cd1         # DEVPTS_SUPER_MAGIC
dont_appraise fsmagic=0x42494e4d     # BINFMTFS_MAGIC
dont_appraise fsmagic=0x73636673     # SECURITYFS_MAGIC
dont_appraise fsmagic=0xf97cff8c     # SELINUX_MAGIC
dont_appraise fsmagic=0x43415d53     # SMACK_MAGIC
dont_appraise fsmagic=0x6e736673     # NSFS_MAGIC
dont_appraise fsmagic=0x27e0eb       # CGROUP_SUPER_MAGIC|
dont_appraise fsmagic=0x63677270     # CGROUP2_SUPER_MAGIC
appraise func=POLICY_CHECK appraise_type=imasig
appraise func=BPRM_CHECK mask=MAY_EXEC appraise_type=imasig

    # evmctl ima_sign -k privkey_ima.pem /etc/sysconfig/ima-policy

    Also, use evmctl to sign /usr/local/bin/sbctl and all executables in the cel_util directory.

    Reboot, turning secure boot back on and setting adding "ima_template=ima-sig ima_policy=tcb"
    to the kernel command line in grub.

    Check that you are getting the right things in
    /sys/kernel/security/ima/ascii_runtime_measurements
    and /sys/kernel/security/ima/policy

    Try creating and running a new test script (which should fail, even if root)

VI. Build UKI Image and sign it (as root): 

   a. Create uki image with ukify - modify the paths and cmdline for your system.

     Mine looked like:

    /usr/lib/systemd/ukify build \
    > --linux=/boot/vmlinuz-6.14.11-300.fc42.x86_64 \
    > --initrd=/boot/initramfs-6.14.11-300.fc42.x86_64.img \
    > --cmdline='root=UUID=09ec011e-54c5-4988-b6fc-32b8cc83e862 ro rd.luks.uuid=luks-52aaca78-7f4d-4bab-bfdd-cb6d250e6bb3 rhgb quiet ima_template=ima-sig ima_policy=tcb'

     (You can get the current cmdline from /proc/cmdline, remove the first boot parameter).

   b. This will create an unsigned UKI file. Sign it with:

    # cp vmlinuz-6.14.11-300.fc42.x86_64.unsigned.efi vmlinuz-6.14.11-300.fc42.x86_64.signed.efi
    # sbctl sign vmlinuz-6.14.11-300.fc42.x86_64.signed.efi
    ✓ Signed /root/vmlinuz-6.14.11-300.fc42.x86_64.signed.efi
    # mkdir /boot/efi/EFI/Linux
    # cp vmlinuz-6.14.11-300.fc42.x86_64.signed.efi /boot/efi/EFI/Linux

   c. enroll the new boot image

     #  kernel-bootcfg --add-uki /boot/efi/EFI/Linux/vmlinuz-6.14.11-300.fc42.x86_64.signed.efi \
        --boot-order 0 --title "Fedora 42 UKI"

   d. reboot

      (The UKI will now be the default UEFI boot. You can see the UEFI boot menu if you press
      F8 at boot. The new UKI boot option will be the default at the top of the UEFI boot menu.)

      Note that you will need to enter the LUKS password, since the PCRs have changed.

   e. reenroll the LUKS key for vda3, vda4, and vda5 as in:

     # systemd-cryptenroll /dev/vda3 --tpm2-device=auto --tpm2-seal-key-handle=0x81000001

     reboot

VII. Run verify

   WHEW!

    Now that everything is installed and configured, you can check things out:

    Check out the keyrings with

# keyctl show %:.platform
# keyctl show %:.machine
# keyctl show %:.ima
                

    Test the attestation verification with:    

    # cd /home/dave/cel_util
    # ./verify

This should yield the following attestation  verification summary:

Some things to note in the summary:

• IMA events are ongoing, and getting the PCR values from the TPM and getting teh event log from the kernel are not synchronized. In the example verifier, the PCR values are retrieved first, and then the IMA event log. This way there may be events at the end of the event log that were not yet extended into PCR-10 when the PCR value was read. The verifier checks after each event in the log to see if the PCR-10 matches. In this example case the result "MATCHED EARLIER" indicates that there were events in the log after the PCR-10 value matched. This is normal.

• "verfified by ima-sig" indicates that the signatures in the ima-sig template have successfully been verified against one of the Fedora signing key certificates or the local IMA certificate.

• The early IMA events are not verified by ima-sig, as they were in the initramfs, which does not have signed files. The entire UKI file is signed to protect against changes.
  
  

VII. Clean Up

Once Everything is tested and working, you may want to move the secure boot and IMA private signing keys off of the platform (to somewhere safe), so that attackers cannot use them to sign malicious efi images with sbctl or malicious executables or policies with evmctl. The sensitive private keys are:

/var/lib/sbctl/PK/PK.key
/var/lib/sbctl/KEK/KEK.key
/var/lib/sbctl/db/db.key

~/ima-evm-utils/examples/ima-local-ca.priv
~/ima-evm-utils/examples/privkey_ima.pem

dracut --kver $(uname -r) --force --add integrity