linux-kernel - Re: RFC: New LSM to control usage of x509 certificates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Oct 2023 10:05:25 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>,
        Mickaël Salaün <mic@...ikod.net>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org
Subject: Re: RFC: New LSM to control usage of x509 certificates

On Thu, Oct 5, 2023 at 6:32 AM Mickaël Salaün <mic@...ikod.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ël Salaün 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ël Salaün <mic@...ikod.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@...ux.ibm.com> wrote:

[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 set of
> > > > kernel usages, while still letting users configure these constraints.
> > >
> > > 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 procedures
> > > and policies, so making something work for everyone is difficult.  Letting 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

-- 
paul-moore.com