Received-SPF: pass (google.com: domain of linux-kernel+bounces-52996-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20230710102319.19716-3-greg@enjellic.com> <ffdd5e4d10865da5f767df53b12bb6db@paul-moore.com>
 <20240108114324.GA4085@wind.enjellic.com>
In-Reply-To: <20240108114324.GA4085@wind.enjellic.com>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 5 Feb 2024 11:09:28 -0500
Message-ID: <CAHC9VhR+Sukfi+-7TTxK2Paxon6i+zDxaELzXUZ=eBOUMf9nwA@mail.gmail.com>
Subject: Re: [PATCH 2/13] Add TSEM specific documentation.
To: "Dr. Greg" <greg@enjellic.com>
Cc: 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 Mon, Jan 8, 2024 at 6:43=E2=80=AFAM Dr. Greg <greg@enjellic.com> wrote:
> On Wed, Jan 03, 2024 at 11:00:33PM -0500, Paul Moore wrote:
> > On Jul 10, 2023 "Dr. Greg" <greg@enjellic.com> wrote:
> > >
> > > An entry was added to the ABI testing documentation to document
> > > the files in the TSEM management filesystem.
> > >
> > > The file documenting the kernel command-line parameters was
> > > updated to document the TSEM specific command-line parameters
> > >
> > > The primary TSEM documentation file was added to the LSM
> > > administration guide and the file was linked to the index of LSM
> > > documentation.
> > >
> > > Signed-off-by: Greg Wettstein <greg@enjellic.com>
> > > ---
> > >  Documentation/ABI/testing/tsem                |  828 +++++++++
> > >  Documentation/admin-guide/LSM/index.rst       |    1 +
> > >  Documentation/admin-guide/LSM/tsem.rst        | 1526 +++++++++++++++=
++
> > >  .../admin-guide/kernel-parameters.txt         |   18 +
> > >  4 files changed, 2373 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/tsem
> > >  create mode 100644 Documentation/admin-guide/LSM/tsem.rst

..

> > I don't want to assume too much about the TSEM design, but I'm
> > guessing the aggregate is intended to be a deterministic value based
> > on the PCRs and therefore it seems like there is value in providing
> > a clear explanation of how it is calculated.
>
> The aggregate is the linear extension sum over PCR registers 0 through
> 8 using the namespace hash function, we will cook up a generic
> description, although it should be a common enough concept for anyone
> working on trusted system implementations.

The Linux kernel documentation is used by a wide variety of
administrators, users, and developers with varying backgrounds, I
would recommend assuming very little about the documentation's
audience.  This is not to say that you need to explain everything
yourself, referring interested readers to established, publicly
available sources of background information can be acceptable.

> > > +           trusted pid=3DPID key=3DHEXID
> > > +                   The trusted keyword is used by a trust
> > > +                   orchestrator to indicate that the process
> > > +                   identified by the PID argument should be
> > > +                   allowed to run in trusted status after the
> > > +                   modeling of a security event.
>
> > I mentioned this quite a few times in my review of the previous
> > patchset, PIDs are not a safe way to identify a process in the
> > system.  PID reuse/recycling is a real danger and you need to
> > account for this risk.
>
> We will defer that discussion to our previous e-mail where we
> discussed how this is addressed.

Adding a secret key/token/etc. may provide some additional
authentication benefits, but it doesn't entirely solve the PID
identification issue, it only reduces the likelihood of a process
misidentification.  We need to do better for new
designs/implementations; look at the pidfd work as an example of work
that has gone into reducing/eliminating the use of PIDs to identify
processes.

--=20
paul-moore.com