Lennart Poettering
8e6587679b
So far you had to pick: 1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor blesses your setup via signature) or 2. Use a pcrlock policy (i.e. local system blesses your setup via dynamic local policy stored in NV index) It was not possible combine these two, because TPM2 access policies do not allow the combination of PolicyAuthorize (used to implement #1 above) and PolicyAuthorizeNV (used to implement #2) in a single policy, unless one is "further upstream" (and can simply remove the other from the policy freely). This is quite limiting of course, since we actually do want to enforce on each TPM object that both the OS vendor policy and the local policy must be fulfilled, without the chance for the vendor or the local system to disable the other. This patch addresses this: instead of trying to find a way to come up with some adventurous scheme to combine both policy into one TPM2 policy, we simply shard the symmetric LUKS decryption key: one half we protect via the signed PCR policy, and the other we protect via the pcrlock policy. Only if both halves can be acquired the disk can be decrypted. This means: 1. we simply double the unlock key in length in case both policies shall be used. 2. We store two resulting TPM policy hashes in the LUKS token JSON, one for each policy 3. We store two sealed TPM policy key blobs in the LUKS token JSON, for both halves of the LUKS unlock key. This patch keeps the "sharding" logic relatively generic (i.e. the low level logic is actually fine with more than 2 shards), because I figure sooner or later we might have to encode more shards, for example if we add further TPM2-based access policies, for example when combining FIDO2 with TPM2, or implementing TOTP for this.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack