Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
MIME-Version: 1.0
References: <CEA476C1-4CE5-4FFC-91D7-6061C8605B18@oracle.com>
 <ba2f5560800608541e81fbdd28efa9875b35e491.camel@linux.ibm.com>
 <932231F5-8050-4436-84B8-D7708DC43845@oracle.com> <7335a4587233626a39ce9bc8a969957d7f43a34c.camel@linux.ibm.com>
 <FD6FB139-F901-4E55-9705-E7B0023BDBA8@oracle.com> <1149b6dbfdaabef3e48dc2852cc76aa11a6dd6b0.camel@linux.ibm.com>
 <4A0505D0-2933-43BD-BEEA-94350BB22AE7@oracle.com> <20230913.Ceifae7ievei@digikod.net>
 <D0F16BFD-72EB-4BE2-BA3D-BAE1BCCDCB6F@oracle.com> <20230914.shah5al9Kaib@digikod.net>
 <20231005.dajohf2peiBu@digikod.net>
In-Reply-To: <20231005.dajohf2peiBu@digikod.net>
From:   Paul Moore <paul@paul-moore.com>
Date:   Thu, 5 Oct 2023 10:05:25 -0400
Message-ID: <CAHC9VhQioMnXdbBugn3h8TBmOPvv_pCehMh8ON5LOOPmt1=6LA@mail.gmail.com>
Subject: Re: RFC: New LSM to control usage of x509 certificates
To:     Eric Snowberg <eric.snowberg@oracle.com>,
        =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>
Cc:     "Serge E. Hallyn" <serge@hallyn.com>,
        Mimi Zohar <zohar@linux.ibm.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        linux-security-module@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Oct 5, 2023 at 6:32=E2=80=AFAM Micka=C3=ABl Sala=C3=BCn <mic@digiko=
d.net> wrote:
>
> The initial subject was "Re: [PATCH] certs: Restrict blacklist updates
> to the secondary trusted keyring":
> https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@oracle.=
com/
>
> On Thu, Sep 14, 2023 at 10:34:44AM +0200, Micka=C3=ABl Sala=C3=BCn wrote:
> > CCing the LSM mailing list for this potential new LSM proposal:
> > On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> > > > On Sep 13, 2023, at 4:21 AM, Micka=C3=ABl Sala=C3=BCn <mic@digikod.=
net> wrote:
> > > > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> > > >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wro=
te:

[Just a reminder that trimming massive emails to the relevant portions
is a nice thing to do]

> > > > A complementary approach would be to create an
> > > > LSM (or a dedicated interface) to tie certificate properties to a s=
et of
> > > > kernel usages, while still letting users configure these constraint=
s.
> > >
> > > That is an interesting idea.  Would the other security maintainers be=
 in
> > > support of such an approach?  Would a LSM be the correct interface?
> > > Some of the recent work I have done with introducing key usage and CA
> > > enforcement is difficult for a distro to pick up, since these changes=
 can be
> > > viewed as a regression.  Each end-user has different signing procedur=
es
> > > and policies, so making something work for everyone is difficult.  Le=
tting the
> > > user configure these constraints would solve this problem.

I can't say that I have been following this thread very closely, but I
see no reason why we wouldn't support a LSM that enforces access
controls on certificates/keys based on their attributes/properties.
We do have some LSM control points for the kernel keyring, which are
used by at least one LSM, but I'm sure you would probably need some
additional control points.

If you are interested in pursuing the creation of a new LSM, and
likely new LSM hooks, we do have some documented guidelines you should
keep in mind:

* https://github.com/LinuxSecurityModule/kernel/blob/main/README.md

--=20
paul-moore.com