Re: [PATCH 02/14] Add TSEM specific documentation.

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

On Tue, Feb 14, 2023 at 01:18:45PM +0100, Roberto Sassu wrote:
> On Tue, 2023-02-14 at 05:58 -0600, Dr. Greg wrote:
> > Our personal prejudice is that these types of measurements are of
> > limited value, which is why we introduce in TSEM, the notion of the
> > 'state' value for a model, discussed below.
> > 
> > I would have to go looking on lore for a reference to the exact thread
> > but Roberto Sassu had offered up a patch set for IMA that addressed
> > the deficiency of these types of measurements.

> Hi Greg

Good morning Roberto, thank you for taking the time to follow up,
pleasant to hear from you.

> yes, this:
> 
> https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/
> 
> DIGLIM makes the PCR extended with software measurements deterministic,
> independent from how processes are scheduled, at the cost of not
> knowing if files with matching digests from a list were accessed or
> not, and in which order.

Yes, DIGLIM, I remember the patch series you sent out but couldn't put
a name to it when I wrote the reply to Paul.

Our efforts and work share the same issues with respect to the
indeterminism of strictly linear extension measurements, particularly
now in the age of ubiquitous SMP.

The 'state' value supported by the Quixote model is designed to
address the same problem and has worked extremely well for us.  Our
implementation only sorts the security state event points that have
been 'touched' by the execution trajectory, so it does provide a
measurement of the events that have occurred.

Like DIGLIM, you lose the the ordering of the events, but we also
provide the linear sequence of security state points, and its classic
measurement value, if one wants to go down the rabbit hole of figuring
out if the integrity of the system has been affected by process
scheduling.

Frankly, I don't see the current state of the art in trusted systems
being in a position to worry about that at this point in time.

> But, in exchange, you can seal a TLS key to IMA measurements that is
> available for handshakes as long as the system does not execute
> something unknown. After that, you have to reboot to use the key
> again.

The same rationale for why we developed the notion of the model
'state' value.

We also look at the 'state' value as a method for a containerized
workload, coming out of a CI/CD development framework, to provide an
attestation of a single value to indicate whether or not the workload
is correct or trusted.

We believe this will become increasingly important as technologies
like TDX, and AMD's equivalent come forward, that will be requiring
attestation as a function of the 'boot' sequence.

> (Didn't read your proposal yet.)

Once you get a chance to look at Quixote/TSEM and things settle down
for us a a bit, we should chat about a common kernel framework for
cacheing digest values as our needs are quite similar.  There would
seem to be no compelling reason to build separate implementations of
the same technology.

Our current digest cache was only driven by the mandates of simplicity
and correctness.  Our plans are to add the equivalent of a Bloom
filter in front of a bucket of lists that key on the MSB of the digest
value.  If I remember correctly, you had expended efforts on
optimizing your implementation.

One ends up with a lot of security event state points when you boot a
modern general purpose Linux administration.

> Roberto

Thanks again, will look forward to chatting about these issues
further.

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity