From: Lennart Poettering Date: Mon, 23 Oct 2023 08:27:14 +0000 (+0200) Subject: update TODO X-Git-Tag: v255-rc1~27^2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=refs%2Fpull%2F28891%2Fhead;p=thirdparty%2Fsystemd.git update TODO --- diff --git a/TODO b/TODO index 021994a7707..f1a269db29d 100644 --- a/TODO +++ b/TODO @@ -144,6 +144,23 @@ Features: root=nvme::::: to boot directly from nvme-oF +* pcrlock: + - make signed PCR work together with pcrlock + - add kernel-install plugin that automatically creates UKI .pcrlock file when + UKI is installed, and removes it when it is removed again + - automatically install PE measurement of sd-boot on "bootctl install" + - write generated pcrlock signature files to the ESP as credential, one for + each installed OS & pick up generated pcrlock signature file in sd-stub, + pass it via initrd to OS + - pre-calc sysext + kernel cmdline measurements + - pre-calc cryptsetup root key measurement + - maybe make systemd-repart generate .pcrlock for old and new GPT header in + /run? + - Add support for more than 8 branches per PCR OR + - add "systemd-pcrlock lock-kernel-current" or so which synthesizes .pcrlock + policy from currently booted kernel/event log, to close gap for first boot + for pre-built images + * add a new systemd-project@.service that is very similar to user@.service but uses DynamicUser=1 and no PAMName= to invoke an unprivileged somewhat light-weight service manager. Use HOME=/var/lib/systemd/projects/%i as home @@ -296,54 +313,6 @@ Features: * systemd-mount should only consider modern file systems when mounting, similar to systemd-dissect -* new "systemd-pcrlock" component for dealing with PCR4. Design idea: - 1. define /{etc,usr,var/lib}/pcrlock.d//.pcrlock - 2. these files contain list of hashes that will be measured when component is - run, per PCR - 3. each component involved in the boot that is deterministically measured can - place one or more of these files in those dirs (shim, sd-boot, - sd-stub/UKI, cryptsetup, pcrphase, pcrfs, …) - 4. since each component has its own dir, with multiple files in them, package - such as kernels (of which there can be multiple installed at the same - time) can be grouped together: only one of them is measured at a time. - 5. whenever a new component is added or an old one removed, or the PCR lock - shall be relaxed or tightened the systemd-pcrlock tool is invoked. - 6. tool iterates through all these files, orders them alphabetically by - component, then matches them up with current measurements (as per uefi - event log), identifying by hash, accepting that the "beginning" of the - measurements might not be recognizable. - 7. Then calculates expected PCR values starting with the "unrecognized - head" from the event log, then continuing with all of components - defined via the .pcrlock files (but dropping out the "recognized tail" - from the uefi event log). (This might mean combinatorial explosion, if - there are multiple shims, multiple sd-boot, and so on.) - 8. Generates a public/private key pair on the TPM - 9. Generates a counter object in the TPM, with a policy that allows only - one-by-one increase with signature policy by the public/private key pair. - 10. now signs policies of all expected PCR values with the generated keypair, - using all combinations of components defined in the .pcrlock files - restricting it to the counter + 1. - 11. locks down the keypair with a signed policy with its own public key - 12. generates JSON file of all these policies with their signatures, drops - them as singleton in ESP - 13. increases the counter by one. - 14. after boot sd-stub picks JSON up from ESP, passes it to userspace via - .extra - 15. JSON contained policies can now be used to unlock disk as well as the - public/key itself for signing further policies, as well as increment for - the counter - 16. whenever any of the components above is added/removed new JSON file with - signatures for counter + 1 is generated, dropped in ESP, then counter - increased. (i.e. this means the "recognized tail" of the event log is - deterministically swapped out) - 17. when firmware update is expected, relaxed signed policy is generated for - next boot only valid if counter is increased (this means the - "unrecognized head" for the event log can change without losing access) - 18. on every boot checks if releaxed policy is in effect, if so, new strict - policy is generated and counter increased. - Net result: Removes downgrade attack surface + Locks OS to firmware + Allows - downgrades within bounds - * add another PE section ".fname" or so that encodes the intended filename for PE file, and validate that when loading add-ons and similar before using it. This is particularly relevant when we load multiple add-ons and want to @@ -466,30 +435,6 @@ Features: * SIGRTMIN+18 and memory pressure handling should still be added to: hostnamed, localed, oomd, timedated. -* in order to make binding to PCR 4 realistic: - - generate one keypair "U" and store it in a tpm2 nvindex. - - Generate another keypair "P" and store it in a second tpm2 nvindex. - - allocate a persistent counter object "C" in the tpm2 - - Enroll all user objects (i.e. luks volumes, creds, …) to a tpm2 policy - signed by U. - - Lock both U and P down with a tpm2 policy signed by P (yes, P can only be - used if a signature by P itself can be provided) - - For regular reboots generate a signature for a restrictive PCR4 + counter C - based policy with key P. Place signature in EFI var, so it can be found on - next boot - - For reboots where a firmware update is expected generate a signature with a - more open policy against just counter C. Place signature in same EFI var. - - Increase C whenever switching between these two signature types. - - During early boot, use the signature from the EFI var to unlock U and P. - Use it to generate a signature for unlocking user objects given the current - PCR 4 value, store that away into /run somewhere, for user during the whole - later boot. - - When booting up automatically update the mentioned efi var so that it - contains the restrictive signature. But also generate a signature ahead of - time that could be used in case during the current boot we later detect we might - need to reboot for a firmware update. Store that in /run somewhere, so that - it can be placed in the EFI var, if needed. - * repart/gpt-auto/DDIs: maybe introduce a concept of "extension" partitions, that have a new type uuid and can "extend" earlier partitions, to work around the fact that systemd-repart can only grow the last partition defined. During @@ -1028,12 +973,6 @@ Features: set up the directory so that it can only be accessed if host and app are in order. -* TPM2: extend unlock policy to protect against version downgrades in signed - policies: policy probably must take some nvram based generation counter into - account that can only monotonically increase and can be used to invalidate - old PCR signatures. Otherwise people could downgrade to old signed PCR sets - whenever they want. - * update HACKING.md to suggest developing systemd with the ideas from: https://0pointer.net/blog/testing-my-system-code-in-usr-without-modifying-usr.html https://0pointer.net/blog/running-an-container-off-the-host-usr.html