archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <>
To: Patrick Uiterwijk <>,,,,,,
Subject: Re: [PATCH 0/3] Load keys from TPM2 NV Index on IMA keyring
Date: Thu, 25 Feb 2021 13:50:19 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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.


  parent reply	other threads:[~2021-02-25 21:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 20:32 [PATCH 0/3] Load keys from TPM2 NV Index on IMA keyring Patrick Uiterwijk
2021-02-25 20:32 ` [PATCH 1/3] tpm: Add support for reading a TPM NV Index Patrick Uiterwijk
2021-02-25 21:50   ` Stefan Berger
2021-02-26  1:09   ` Jarkko Sakkinen
2021-02-25 20:32 ` [PATCH 2/3] integrity: Allow specifying flags in integrity_load_cert Patrick Uiterwijk
2021-02-26 21:04   ` Stefan Berger
2021-02-25 20:32 ` [PATCH 3/3] integrity: Load keys from TPM NV onto IMA keyring Patrick Uiterwijk
2021-02-26 21:47   ` Stefan Berger
2021-02-26 21:51     ` Stefan Berger
2021-02-25 21:50 ` James Bottomley [this message]
2021-02-26 21:45   ` [PATCH 0/3] Load keys from TPM2 NV Index on " Ken Goldman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).