public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.
Date: Thu, 4 Jan 2024 21:54:09 -0600	[thread overview]
Message-ID: <20240105035409.GA17707@wind.enjellic.com> (raw)
In-Reply-To: <CAHC9VhSBnKor21HKiLuvn1kPmtHzNZW2j6FfEQ+cab5R1=_Bdw@mail.gmail.com>

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

  reply	other threads:[~2024-01-05  3:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 10:23 [PATCH 00/13] Implement Trusted Security Event Modeling Dr. Greg
2023-07-10 10:23 ` [PATCH 01/13] Update MAINTAINERS file Dr. Greg
2023-07-10 20:00   ` Randy Dunlap
2023-07-15 22:45     ` Dr. Greg
2023-07-10 10:23 ` [PATCH 02/13] Add TSEM specific documentation Dr. Greg
2023-07-11  4:37   ` Randy Dunlap
2023-07-17  0:36     ` Dr. Greg
2023-07-17  1:56       ` Randy Dunlap
2023-08-08 18:48   ` Serge Hallyn
2023-08-11 20:22     ` Dr. Greg
2024-01-04 15:54       ` Paul Moore
2024-01-05  3:54         ` Dr. Greg [this message]
2024-01-04  4:00   ` [PATCH 2/13] " Paul Moore
2024-01-05  2:55     ` Dr. Greg
2024-01-08 11:43     ` Dr. Greg
2024-02-05 16:09       ` Paul Moore
2024-02-19 11:16         ` Dr. Greg
2023-07-10 10:23 ` [PATCH 03/13] Implement CAP_TRUST capability Dr. Greg
2023-08-07 20:21   ` Casey Schaufler
2023-08-15 10:19     ` Dr. Greg
2023-08-15 17:15       ` Casey Schaufler
2023-07-10 10:23 ` [PATCH 04/13] Add TSEM master header file Dr. Greg
2023-08-07 20:39   ` Casey Schaufler
2023-08-10  2:57     ` Dr. Greg
2023-08-10 15:03       ` Casey Schaufler
2023-07-10 10:23 ` [PATCH 05/13] Add primary TSEM implementation file Dr. Greg
2023-08-07 21:00   ` Casey Schaufler
2023-08-11  7:21     ` Dr. Greg
2023-07-10 10:23 ` [PATCH 06/13] Add root domain trust implementation Dr. Greg
2023-07-10 10:23 ` [PATCH 07/13] Implement TSEM control plane Dr. Greg
2023-07-10 10:23 ` [PATCH 08/13] Add namespace implementation Dr. Greg
2023-07-10 10:23 ` [PATCH 09/13] Add security event description export facility Dr. Greg
2023-07-10 10:23 ` [PATCH 10/13] Add event description implementation Dr. Greg
2023-07-10 10:23 ` [PATCH 11/13] Implement security event mapping Dr. Greg
2023-07-10 10:23 ` [PATCH 12/13] Implement an internal Trusted Modeling Agent Dr. Greg
2023-07-10 10:23 ` [PATCH 13/13] Activate the configuration and build of the TSEM LSM Dr. Greg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240105035409.GA17707@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox