Received-SPF: pass (google.com: domain of linux-kernel+bounces-17459-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 4 Jan 2024 21:54:09 -0600
From: "Dr. Greg" <greg@enjellic.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>, linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org, corbet@lwn.net
Subject: Re: [PATCH 02/13] Add TSEM specific documentation.
Message-ID: <20240105035409.GA17707@wind.enjellic.com>
Reply-To: "Dr. Greg" <greg@enjellic.com>
References: <20230710102319.19716-1-greg@enjellic.com> <20230710102319.19716-3-greg@enjellic.com> <ZNKN+ZK6Lfbjb4GZ@jerom> <20230811202254.GA9401@wind.enjellic.com> <CAHC9VhSBnKor21HKiLuvn1kPmtHzNZW2j6FfEQ+cab5R1=_Bdw@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHC9VhSBnKor21HKiLuvn1kPmtHzNZW2j6FfEQ+cab5R1=_Bdw@mail.gmail.com>
User-Agent: Mutt/1.4i

On Thu, Jan 04, 2024 at 10:54:47AM -0500, Paul Moore wrote:
> On Fri, Aug 11, 2023 at 4:24???PM Dr. Greg <greg@enjellic.com> wrote:
> > On Tue, Aug 08, 2023 at 01:48:25PM -0500, Serge Hallyn wrote:
> > > On Mon, Jul 10, 2023 at 05:23:08AM -0500, Dr. Greg wrote:
> 
> ...
> 
> > > > +of a model.  This allows a TMA to attest to the trust/security status
> > > > +of a platform or workload by signing this singular value and
> > > > +presenting it to a verifying party.
> > > > +
> > > > +In TSEM nomenclature, this singular value is referred to as the
> > > > +'state' of the model.  The attestation model is to use trust
> > > > +orchestrators to generate the state value of a workload by unit
> > > > +testing.  This state value can be packaged with a utility or container
> > > > +to represent a summary trust characteristic that can be attested by a
> > > > +TMA, eliminating the need for a verifying partner to review and verify
> > > > +an event log.
> > > > +
> > > > +TMA's implement this architecture by maintaining a single instance
> > > > +vector of the set of security state coefficients that have been
> > > > +generated.  A state measurement is generated by sorting the vector in
> > > > +big-endian hash format and then generating a standard measurement
> > > > +digest over this new vector.
> >
> > > Are you saying the TMA will keep every meaningful measurement for
> > > the duration of the workload, so that it can always sort them?
> >
> > Correct, every unique security state coefficient.
> >
> > The approach isn't unique and without precedent.  Roberto Sassu is
> > using a similar strategy in order generate a time/order independent
> > PCR value for unlocking TPM sealed keys by parsing RPM and .deb
> > distribution manifests.
> >
> > Paul Moore, in his comments in February to the V1 series, even
> > seriously questioned why we would expose the classic linear extension
> > measurement from a TMA.

> To put my comment from the first revision into the proper context,
> and with my understanding that TSEM's security model does not
> consider event ordering/timing, I questioned what TSEM would expose
>					       ^^^^ why??
> an ordered list of events to userspace in addition to its unordered,
> sorted list.
>
> Either ordering is important to the security model, in which case you
> expose the ordered list, or it isn't, in which case you expose the
> list in whatever form is most convenient for the tooling/model; it
> makes little sense to me to expose both.

As a generic clarification in furtherance of getting everyone on the
same page with respect to the focus of our work.

TSEM is about providing generic infrastructure for security modeling
and anomaly detection that acts at the most precise level of security
instrumentation that is available.

Secondary to that pursuit, TSEM offers security architects the ability
to choose from either a time dependent or a time independent appraisal
of a security modeling namespace.

The TSEM 'trajectory' file is always time ordered with respect to the
first unique occurrence of a security event.  In the V3 release, these
trajectory entries include a nanosecond timestamp reference, relative
to boot, of when the event occurred.

The 'measurement' pseudo-file allows a relying party to verify that
the trajectory list, as presented, is order/time consistent, if that
is what they choose to evaluate.

The 'state' pseudo-file allows a relying party to make a decision on
whether or not the security status of the system is idempotent, from
an event perspective, with a known reference state.

It addresses, among other issues, the problem that IMA is currently
facing with the fact that handling and examining unconstrained event
logs can be problematic from a number of perspectives.

Alternately, now in V3, a security model implementator can specify
that a security event stream from a modeling namespace be
asynchronously exported in its entirety and dealt with in whatever
fashion an external evaluator desires.

So TSEM doesn't implement or advocate a security model as much as it
implements security infrastructure.

> paul-moore.com

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project