From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tadeusz Struk <tadeusz.struk@intel.com>, jarkko.sakkinen@linux.intel.com
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org, jgg@ziepe.ca,
mingo@redhat.com, jeffrin@rajagiritech.edu.in,
linux-integrity@vger.kernel.org, will@kernel.org,
peterhuewe@gmx.de
Subject: Re: [PATCH =v2 3/3] tpm: selftest: cleanup after unseal with wrong auth/policy test
Date: Thu, 12 Dec 2019 15:54:45 -0500 [thread overview]
Message-ID: <1576184085.10287.13.camel@HansenPartnership.com> (raw)
In-Reply-To: <c3bffb8c-d454-1f53-7f7e-8b65884ffaf6@intel.com>
On Thu, 2019-12-12 at 12:49 -0800, Tadeusz Struk wrote:
> On 12/12/19 11:51 AM, James Bottomley wrote:
> > TPM2_Clear reprovisions the SPS ... that would make all currently
> > exported TPM keys go invalid. I know these tests should be
> > connected to a vTPM, so doing this should be safe, but if this
> > accidentally got executed on your laptop all TPM relying functions
> > would be disrupted, which doesn't seem to be the best thing to hard
> > wire into a test.
>
> That is true, but it will need to be executed as root, and root
> should know what she/he is doing ;)
Not in the modern kernel resource manager world: anyone who is in the
tpm group can access the tpmrm device and we haven't added a dangerous
command filter like we promised we would, so unless they have actually
set lockout or platform authorization, they'll find they can execute it
> > What about doing a TPM2_DictionaryAttackLockReset instead, which is
> > the least invasive route to fixing the problem ... provided you
> > know what the lockout authorization is.
>
> I can change tpm2_clear to tpm2_dictionarylockout -c if we want to
> make it foolproof. In this case we can assume that the lockout auth
> is empty.
Well, if it isn't TPM2_Clear would refuse to execute as well since that
requires either lockout auth or platform + physical presence.
James
next prev parent reply other threads:[~2019-12-12 20:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 17:48 [PATCH =v2 1/3] tpm: fix invalid locking in NONBLOCKING mode Tadeusz Struk
2019-12-12 17:48 ` [PATCH =v2 2/3] tpm: selftest: add test covering async mode Tadeusz Struk
2019-12-17 1:55 ` Jarkko Sakkinen
2019-12-12 17:48 ` [PATCH =v2 3/3] tpm: selftest: cleanup after unseal with wrong auth/policy test Tadeusz Struk
2019-12-12 19:51 ` James Bottomley
2019-12-12 20:49 ` Tadeusz Struk
2019-12-12 20:54 ` James Bottomley [this message]
2019-12-12 21:07 ` Tadeusz Struk
2019-12-12 21:11 ` James Bottomley
2019-12-17 10:37 ` Jarkko Sakkinen
2019-12-17 1:32 ` [PATCH =v2 1/3] tpm: fix invalid locking in NONBLOCKING mode Jarkko Sakkinen
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1576184085.10287.13.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jeffrin@rajagiritech.edu.in \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterhuewe@gmx.de \
--cc=peterz@infradead.org \
--cc=tadeusz.struk@intel.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.