Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2023-01-11 at 07:50 -0600, William Roberts wrote:
> On Wed, Jan 11, 2023 at 6:31 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2023-01-11 at 17:49 +0530, Sughosh Ganu wrote:
[...]
> > 
> > > [  217.219048] tpm tpm0: A TPM error (2328) occurred unsealing
> > 
> > Error 2328 is TPM_RC_REFERENCE_S0 - the 1st authorization session
> > handle references a session that is not loaded
> > 
> > So it looks like the session is still context saved, pointing to an
> > error in the toolkit.
> > 
> 
> Yes, this jogged my memory that we talked about implementing this
> between Imran (The other main developer) and I. If we don't context
> save in the tool, both tpm2-abrmd and in-kernel will flush the
> handle.
> 
> I think the cleanest option would be to add a --wait-for-sighup
> option where the tool sleeps until sighup is delivered. For scripts,
> folks could just lunch it in the background, grab the handle output
> and then kill -s sighuhp %1 or whatever.

I don't think that would work: The in-kernel resource manager will
context save the session while the userspace program isn't using the
TPM (so that's while a TPM device read/write is active), so even if you
hold the process running or even the /dev/tpmrm0 fd open, the session
won't be in a state to pass into the kernel.  What you really have to
do to get this to work is to bypass the resource manager because you're
trying to share a session between two otherwise separately managed uses
of the TPM.

Using a session constructed elsewhere is a security problem anyway
because you can't share nonces, so the policy patches that stalled a
year or so ago fixed this by allowing the kernel itself to construct
the policy session, so you didn't have to pass in the handle:

https://lore.kernel.org/linux-integrity/20210521004401.4167-1-James.Bottomley@HansenPartnership.com/

James