Re: [RFC] IMA Log Snapshotting Design Proposal - unseal

["Dr. Greg" <greg@enjellic.com>]

On Wed, Aug 30, 2023 at 03:12:39PM -0400, Ken Goldman wrote:

Good morning, I hope the day is going well for everyone.

> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
> 
> >For remote attestation to work, the service will need to know how to
> > validate the snapshot_aggregate entry in the IMA log.  It will have
> >to read the PCR values present in the template data of
> >snapshot_aggregate event in the latest IMA log, and ensure that the
> >PCR quotes align with the contents of the past UM_snapshot_file(s).
> >This will re-establish the chain of trust needed for the device to
> >pass remote attestation.  This will also maintain the ability of the
> >remote-attestation-service to seal the secrets, if the client-server
> > use TPM unseal mechanism to attest the state of the device.

> I think that seal/unseal to IMA PCRs is futile.  Since boot is
> multi-threaded, the IMA PCR is unpredictable even when valid.

Yes, unbiased observation calls into question the relevancy of the
2000-2002/Palladium model for TPM based integrity attestation, both
from a hardware and software perspective.  In addition to interference
by standard scheduling artifacts, the notion of everything being SMP
makes PCR invariancy a hopeless issue.

In fact, our trust orchestrators demonstrate that the very act of
modeling, ie computing file digests, causes an event ordering that
will be different from subsequent invocations when the digest value is
cached.  A concept that should be of no surprise to anyone fluent in
the writings of Heisenberg... :-)

We discuss this at some length, along with our proposed solution, in
the documentation that we provide with our TSEM LSM:

https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t

TSEM is a superset of IMA, given that file checksums are just one of
the components in the security state coefficients that our security
modeling is based on, but the issue is the same.

Having an invariant 'security state' value also simplifies the
attestation processw, since the relying party only needs to evaluate a
single signed value in order to verify that the workload has been
consistent with its desired security model.

It is also becoming increasingly apparent that advancing the art of
integrity and trusted systems will become problematic without the
ability to 'namespace' or partition integrity on a workload by
workload basis.  We also introduce support for that with our security
modeling namespaces.

I missed copying the LSM list on my reply, but I discussed some of the
challenges that TDX, and COCO in general, raises to current integrity
infrastructures in the following thread, which should be easily
locatable on the LKML or COCO lists:

tsm: Introduce a shared ABI for attestation reports

Given our experiences, it is difficult to understand how the notion of
'legitimate' confidential computing is going to grow from 7 billion
dollars to 55 billion dollars over the next five years without the
concept of better 'trust orchestration'.

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity