| Message ID | 20210225203229.363302-1-patrick@puiterwijk.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Load keys from TPM2 NV Index on IMA keyring | expand |
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
On 2/25/2021 4:50 PM, James Bottomley wrote: > On Thu, 2021-02-25 at 21:32 +0100, Patrick Uiterwijk wrote: >> >> 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. Some ideas on this: 1 - Create the index such that it can be deleted by the platform (pre-OS, physical presence) but not post-OS. E.g, create with TPMA_NV_POLICY_DELETE in the owner hierarchy, and with a zero length policy. TPM2_Clear will delete it but the owner cannot. 2 - Permit reads with no authorization. 3 - Permit the first write (when the OS is first installed) with no authorization. E.g., write if written is clear. If worried about a malicious first write, remove this step and use #5. 4 - Permit writes when a password is supplied locally, the password supplied during first install. 5 - For remote update, permit a write when given a signed authorization by an update serve, e.g. a tang server. E.g., the index policy says "accepts writes signed by this key". The key signs an authorization to write a specific new value to NV. Also: It is not enough for the application to read the index data. The application must read the index metadata (the Name in TCG jargon) to verify that the index has the correct authorization metadata.