UKI: measured systemd-sysext

[mudler]

Having UKI means we have most of the OS visible, even if it can't be tampered with. however, we can use systemd sysextensions to overlay portion of the system during boot to have portion of the system encrypted as well. The systemd-sysextensions can actually be in the encrypted portion and be measured by using the systemd-* features.

Requirements:

• A mechanism that loads systemd-sysextension(s) during runtime as part of a Kairos system (provided by systemd, maybe needs to be configured by us (?))
• The systemd-sysextensions can be built offline, and bundled into the installable images that will be installed in the final system
• A mechanism to build systemd-sysextensions from OCI images (https://github.com/kairos-io/oci2sysext) and use it seamlessly with osbuilder
• A mechanism to upgrade bundled systemd-sysext automatically with kubernetes (e.g. using kubernetes SUC plans, as we do for upgrades) or manually (by issuing manual commands)

[Itxaka]

the one in charge of loading and measuring stuff is systemd-stub:

https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#

[Itxaka]

I had a quick look at this.

I created a sysext raw image and it was properly copied into place. Supposedly TPM13 was used to measure this but we dont do anything with that.

Similarly, files foo.efi.extra.d/*.raw are packed up in a cpio archive and placed in the /.extra/sysext/ directory in the initrd file hierarchy. This is supposed to be used to pass additional system extension images to the initrd. See [systemd-sysext(8)](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html#) for details on system extension images. The generated cpio archive containing these system extension images is measured into TPM PCR 13 (if a TPM is present).

I have no idea how this would fit in our current workflow.

• luks devices are locked to TPM11
• sysext are measured under TPM13
• measurements are done while building the EFI file, raw images are ignored as they are not part of the uki efi file
• we would need to manually measure TPM13? and copy those extensions to the /var/lib/extensions during immucore init only if the measurements are correct?
• How would we measure those files? (hint: talos code can measure things, maybe we can leverage that?)
• What prevents a malicious user from directly copying those raw files into the extensions dir manually? (sudo permissions only)?
• currently no way of taking those measurements into the luks devices measurements. Maybe pcrlock could help us in the future?
• no way of expansion with new sysext files if we check for the measurements on TPM13, as if you add or remove a new one, measurements wont match.

Maybe we have to check with upstream systemd to see what they recommend doing here? I know thye are gonna say pcrlock, which works for ALL TPM slots but... that is v255 only....

[jimmykarily]

This is for Kairos 3.1.0, do we mind if it's only supported on systemd 255 + ?

[Itxaka]

This is for Kairos 3.1.0, do we mind if it's only supported on systemd 255 + ?

We should not mind as we are also bumping kcrypt to support only 255 and higher. Plus 3.1 is Ubuntu 24 + fedora 40 which should be systemd 255 anyway

[jimmykarily]

The docs say:

On access they should be further validated: in case of the credentials case by encrypting/authenticating them via TPM, as exposed by systemd-creds encrypt -T (see [systemd-creds(1)](https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html#) for details); in case of the system extension images by using signed Verity images.

what on earth is a "signed Verity image"?

[jimmykarily]

One option would be to bind decryption of partitions to PCR 13 (which systemd already populates with measurements of sysext) and use a process like this to upgrade or change them: #2429 (comment)

[mudler]

Just for the records, seems there is no support for systemd-sysext to be measured as for now: https://lists.freedesktop.org/archives/systemd-devel/2024-May/050294.html

[Itxaka]

After a lot of research I dont think we can do this easily ourselves.

It will requrie to basically roll and adapt our own stuff, identical to what the policy does for pcr11 and uki measurements but with raw images. But in a more complex way even.

So I think we need to wait and track what upstream will do on this (check systemd mailing list with Leonnard's email) otherwise we have to do a ton of work in areas which are a bit outside of our knowledge.

[Itxaka]

@mudler I dont remember but this was a spike no? So ti should be ok to close it with the findings?

[Itxaka]

The IMA talked about in systemd lists is about https://sourceforge.net/p/linux-ima/wiki/Home/

[Itxaka]

seems to measure if proper cmdline is passed:

root@localhost:~# head -5 /sys/kernel/security/ima/ascii_runtime_measurements
10 9e1843447646c0906682e52dce606909337f852b ima-ng sha256:159a4ef943f8ac7929e20043e45b6b244a68337bdb982c23fe81dcf5d6a00e5d boot_aggregate
10 b3c59f78854f70b2adca9175fdfc961a7462931a ima-ng sha1:08f90a3091c57dcee7f9bfa558a97e30b59c5f18 /usr/lib/modules/6.5.0-35-generic/kernel/drivers/firmware/qemu_fw_cfg.ko.zst
10 4353f509a52fe74b42756305cd4ac0117438bedf ima-ng sha1:b32a972a1ae83beb130ae7ce9213404baae47e3c /usr/lib/modules/6.5.0-35-generic/kernel/drivers/gpu/drm/drm.ko.zst
10 89ecde070fa291b58f0c35fbd8c8585dd2011a70 ima-ng sha1:e148a64438042cb7ea027c26498b5545d3b8e86b /usr/lib/modules/6.5.0-35-generic/kernel/drivers/gpu/drm/drm_kms_helper.ko.zst
10 6fbeb2be6fb2e70c5ced7cf1bcbc078990d20e7b ima-ng sha1:f52ba4990a13532f4afcb66aa50037fa980b865f /usr/lib/modules/6.5.0-35-generic/kernel/drivers/gpu/drm/drm_shmem_helper.ko.zst
root@localhost:~# 

ima=on image_policy=secure-boot image_audit=1

[Itxaka]

tIm not sure how we can use this though lol

[mudler]

@mudler I dont remember but this was a spike no? So ti should be ok to close it with the findings?

Correct, we need to find out a way to go - do we have the follow ups card created to track the needed work?

[Itxaka]

This seems a more nicer explanation https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture

[The kernel integrity sub-system](https://sourceforge.net/p/linux-ima/wiki/Home/) can be used to detect if a file has been altered (accidently or maliciously), both remotely and/or locally. It does that by appraising a file's measurement (its hash value) against a “good” value stored previously as an extended attribute ([on file systems which support extended attributes like ext3, ext4. etc](https://en.wikipedia.org/wiki/Extended_file_attributes).). Similar, but complementary, mechanisms are provided by other security technologies like SELinux which depending on policy can attempt to protect file integrity.

We cant use this then becuase they are stored under a FAT fs, and that wont allow attributes.

[Itxaka]

@mudler I dont remember but this was a spike no? So ti should be ok to close it with the findings?

Correct, we need to find out a way to go - do we have the follow ups card created to track the needed work?

Well, thats the thing, other than implementing the systemd-measure+policy generation ourselves, I dont see a good approach to this that its secure and doesnt break the full chain of trust :(

So no idea what work we really need to do here.

[mudler]

@mudler I dont remember but this was a spike no? So ti should be ok to close it with the findings?

Correct, we need to find out a way to go - do we have the follow ups card created to track the needed work?

Well, thats the thing, other than implementing the systemd-measure+policy generation ourselves, I dont see a good approach to this that its secure and doesnt break the full chain of trust :(

So no idea what work we really need to do here.

Let's then create a follow up card for tracking this(our own implementation) , and what would take us to get there, we will discuss then in planning if something that is worth or not. The other option would be to help upstream, correct?

But that would require much time for us before we can actually consume such a feature

[Itxaka]

follow up card for implementation