Received-SPF: pass (google.com: domain of linux-kernel+bounces-16889-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20230710102319.19716-1-greg@enjellic.com> <20230710102319.19716-3-greg@enjellic.com>
 <ZNKN+ZK6Lfbjb4GZ@jerom> <20230811202254.GA9401@wind.enjellic.com>
In-Reply-To: <20230811202254.GA9401@wind.enjellic.com>
From: Paul Moore <paul@paul-moore.com>
Date: Thu, 4 Jan 2024 10:54:47 -0500
Message-ID: <CAHC9VhSBnKor21HKiLuvn1kPmtHzNZW2j6FfEQ+cab5R1=_Bdw@mail.gmail.com>
Subject: Re: [PATCH 02/13] Add TSEM specific documentation.
To: "Dr. Greg" <greg@enjellic.com>
Cc: Serge Hallyn <serge@hallyn.com>, linux-security-module@vger.kernel.org, 
	linux-kernel@vger.kernel.org, corbet@lwn.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 11, 2023 at 4:24=E2=80=AFPM 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 statu=
s
> > > +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 contain=
er
> > > +to represent a summary trust characteristic that can be attested by =
a
> > > +TMA, eliminating the need for a verifying partner to review and veri=
fy
> > > +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 i=
n
> > > +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 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.

--=20
paul-moore.com