You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repo's solution to generating UKIs for OSTree deployments requires a db key or MOK and the PCR policy keys to be resident on the device. This is great for preventing at-rest tampering and brute force but doesn't address the possibility of malware persistence via a bootkit that gains access to the resident keys.
Ideally, we could generate the UKI and sign it during the image build process and that build would occur on transparent and trustworthy infrastructure. However, the way that the OSTree deployment location is injected into early boot is via kernel arguments. Kernel arguments are, rightfully, treated as signed data that must be authenticated and measured into PCR 11.
There are a couple options to resolve this that come to mind:
Use EFI variables to determine which UKI was booted and embed the deployment hash (and index) in the filename. This is discussed at Support UKI ostreedev/ostree#2753.
If the OSTree hash is not specified on the cmdline but OSTree is enabled then show a plymouth or tty console menu for the user to select the correct deployment. Note that this may result in a mismatch between the booted kernel/initrd and the selected deployment but generally that isn't a big problem. If we want to avoid that then it should be possible to fetch the boot checksum, which can be calculated at build, for each deployment in the stateroot and only show those deployments in the menu. We can even skip the menu if there's only one matching deployment for the boot checksum.
The text was updated successfully, but these errors were encountered:
This repo's solution to generating UKIs for OSTree deployments requires a db key or MOK and the PCR policy keys to be resident on the device. This is great for preventing at-rest tampering and brute force but doesn't address the possibility of malware persistence via a bootkit that gains access to the resident keys.
Ideally, we could generate the UKI and sign it during the image build process and that build would occur on transparent and trustworthy infrastructure. However, the way that the OSTree deployment location is injected into early boot is via kernel arguments. Kernel arguments are, rightfully, treated as signed data that must be authenticated and measured into PCR 11.
There are a couple options to resolve this that come to mind:
The text was updated successfully, but these errors were encountered: