Chris Coulson
2348941b5d
systemd-measure can produce multiple signed policies for different phases. However, a policy for a TPM resource that includes these signed policies can currently be satisfied by any policy that is signed with the same key. It can be desirable to bind a resource's policy to one or more specific phases. One way to do this could be to sign policies for different phases or phase combinations with different keys. Another approach is to limit the scope of signed policies using a policy reference. Using a policy reference works because: - The reference is included along with the approved policy digest in the digest that is signed. - The reference argument is included in the authorization policy for a resource via the TPM2_PolicyAuthorize assertion. - During execution of the TPM2_PolicyAuthorize assertion, the TPM checks that the session's current policy digest is the approved policy digest, computes a digest from the approved policy digest and the supplied policy reference, and checks that the resulting digest is the one that was verified by TPM2_VerifySignature (via the returned ticket). This adds a new --policyref argument to systemd-measure which binds all of the signed policies to the specified policy reference. I did consider making this more intelligent by auto-generating policy references for each phase, but this approach provides the most flexibility for now. By making use of the existing --append argument, a signer can produce multiple signed policies with the same key that are bound to any individual phases or combinations of phases. The policy reference is a string without the NULL terminator. It is supplied to the TPM via the TPM2B_NONCE type, which has a maximum size equivalent to the size of the largest digest supported by the TPM. As the signer doesn't know the capabilities of the target TPM, systemd-measure limits the size of the policy reference to 32 bytes, to fit within the size of a SHA256 digest. This also includes the corresponding changes to systemd-cryptenroll and systemd-repart (to add an equivalent --tpm2-public-key-policyref argument so that the policy can be bound to the desired corresponding phase, and to ensure that the policy reference is included in the LUKS2 token metadata), and systemd-cryptsetup (to handle the policy reference stored in the LUKS2 token metadata). This doesn't include policy reference support for credentials yet because it requires a change to the credential headers.
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
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release