On Thu, 2021-02-25 at 21:32 +0100, Patrick Uiterwijk wrote: > The system's signature chain of trust is rooted in hardware and > pivots to the keys baked into the kernel. IMA maintains this > signature chain of trust by requiring any key being added to the IMA > trusted keyring to be signed by a key on the builtin (or secondary) > keyrings. This prevents a local key, needed for signing policies or > other files, from being loaded on the IMA keyring, without requiring > a custom built kernel (or injecting a key and resigning the kernel > image). > > Allow users to load their own public key stored in a specific TPM2 NV > Index, requiring the absence of the Platform Create and Platform > Write attributes on the NV Index, to be loaded on the IMA keyring. > > To test this with the TPM2-software tools with a DER-encoded > imacert.der: > tpm2_nvdefine -C o -s 945 0x184b520 > tpm2_nvwrite -C o -i imacert.der 0x184b520 > > Or with the IBM TSS tools: > tssnvdefinespace -ha 0x184b520 -hi o -sz 945 +at ow +at or > tssnvwrite -hia o -ha 0x184b520 -if imacert.der > > Then after a reboot, the ima keyring should contain the certificate. > > Note that if this feature is enabled, users should make sure an NV > Index is created with accurate attributes to prevent any other users > from writing or deleting the NV Index. Without this precaution, any > user who has access to the TPM would be able to write a key to the NV > Index and have that key loaded on the IMA trusted keyring. > > A distro who wants to enable this feature, for example, should ensure > that the installer defines the NV Index in all cases, and only fills > it if a key was provided by the user. This has some problematic security implications: any member of the tpm group (which is pretty much all users if you use the TPM for user space secrets or other operations) can read and write NV indexes. What does a distro do if the index is occupied on install (because it could be some malicious entity who's put their cert in the index)? > It is strongly adviced that any NV Index created for this purpose has > at least the policy_delete and policywrite attributes set, together > with a non-empty policy. Those flags make sure that the policy (which > would be up to them to define) is required to be satisfied to delete > or write the index. This isn't necessarily good enough. Unless the index has PlatformCreate set, then any member of the tpm group can delete it with TPM2_NV_UndefineIndex. Creating stuff with TPM_NV_PLATFORMCREATE attributes is possible, but whoever does must know the platform policy or auth, so how would any distro get that if it's non standard (and if it is standard then any tpm user can delete the index with TPM2_NV_UndefineSpaceSpecial). The bottom line is I don't see how this could safely be used by a distribution in any standard manner, so why not simply pass the cert in on the command line instead? At least any random user can't then compromise the process. James
