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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
