linux-kernel - Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

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]
Message-ID: <f7f82ef6ed63b91739e9c10cc34ea9931690aeff.camel@linux.ibm.com>
Date: Sun, 05 Jan 2025 07:59:37 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Eric Snowberg <eric.snowberg@...cle.com>
Cc: "open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "ardb@...nel.org"
 <ardb@...nel.org>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "paul@...l-moore.com" <paul@...l-moore.com>,
        "jmorris@...ei.org"
 <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "roberto.sassu@...wei.com" <roberto.sassu@...wei.com>,
        "dmitry.kasatkin@...il.com" <dmitry.kasatkin@...il.com>,
        "mic@...ikod.net"
 <mic@...ikod.net>,
        "casey@...aufler-ca.com" <casey@...aufler-ca.com>,
        "stefanb@...ux.ibm.com" <stefanb@...ux.ibm.com>,
        "ebiggers@...nel.org"
 <ebiggers@...nel.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

On Fri, 2025-01-03 at 23:32 +0000, Eric Snowberg wrote:
> 
> > On Dec 24, 2024, at 10:43 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> > 
> > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> > > Introduce a new LSM called clavis.  The motivation behind this LSM is to
> > > provide access control for system keys.  The access control list is
> > > contained within a keyring call .clavis.  During boot if the clavis= boot
> > > arg is supplied with a key id contained within any of the current system
> > > keyrings (builtin, secondary, machine, or platform) it shall be used as
> > > the root of trust for validating anything that is added to the ACL list.
> > > 
> > > The first restriction introduced with this LSM is the ability to enforce
> > > key usage.  The kernel already has a notion of tracking key usage.  This
> > > LSM adds the ability to enforce this usage based on the system owners
> > > configuration.
> > > 
> > > Each system key may have one or more uses defined within the ACL list.
> > > Until an entry is added to the .clavis keyring, no other system key may
> > > be used for any other purpose.
> > > 
> > > Signed-off-by: Eric Snowberg <eric.snowberg@...cle.com>
> > > ---
> > > Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
> > > MAINTAINERS                                   |   7 +
> > > crypto/asymmetric_keys/signature.c            |   4 +
> > > include/linux/lsm_count.h                     |   8 +-
> > > include/linux/lsm_hook_defs.h                 |   2 +
> > > include/linux/security.h                      |   7 +
> > > include/uapi/linux/lsm.h                      |   1 +
> > > security/Kconfig                              |  10 +-
> > > security/clavis/Makefile                      |   1 +
> > > security/clavis/clavis.c                      |  26 +++
> > > security/clavis/clavis.h                      |   4 +
> > > security/clavis/clavis_keyring.c              |  78 ++++++-
> > > security/security.c                           |  13 ++
> > > .../selftests/lsm/lsm_list_modules_test.c     |   3 +
> > > 14 files changed, 346 insertions(+), 9 deletions(-)
> > > create mode 100644 Documentation/admin-guide/LSM/clavis.rst
> > > create mode 100644 security/clavis/clavis.c
> > > 
> > > diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
> > > new file mode 100644
> > > index 000000000000..0e924f638a86
> > > --- /dev/null
> > > +++ b/Documentation/admin-guide/LSM/clavis.rst
> > > @@ -0,0 +1,191 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +
> > > +======
> > > +Clavis
> > > +======
> > > +
> > > +Clavis is a Linux Security Module that provides mandatory access control to
> > > +system kernel keys (i.e. builtin, secondary, machine and platform). These
> > > +restrictions will prohibit keys from being used for validation. Upon boot, the
> > > +Clavis LSM is provided a key id as a boot parameter.  This single key is then
> > > +used as the root of trust for any access control modifications made going
> > > +forward. Access control updates must be signed and validated by this key.
> > > +
> > > +Clavis has its own keyring.  All ACL updates are applied through this keyring.
> > > +The update must be signed by the single root of trust key.
> > > +
> > > +When enabled, all system keys are prohibited from being used until an ACL is
> > > +added for them.
> > 
> > Until the single key has been loaded, Clavis is not enabled.  Any key on the
> > system trusted keyrings remains usable for any purpose.
> > 
> > -> When enabled, meaning the single key has been loaded onto the Clavis keyring,
> > all system keys are prohibited ...
> > 
> > Until clavis is enabled, in my opinion the defaults should be restrictive (e.g.
> > CONFIG_INTEGRITY_CA_MACHINE_KEYRING,
> > CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN). Once Clavis is enabled,
> > based on a new helper function is_clavis_enforced() we could consider relaxing
> > some of the existing keyring requirements (e.g. kernel modules).

For example, kernel/module/signing.c: mod_verify_sig() would be updated to check
whether Clavis is configured and enabled and then search/use keys on the other
system keyrings.

> 
> If I made this change, would it be acceptable to update the Kconfig 
> description for CONFIG_INTEGRITY_CA_MACHINE_KEYRING and CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN 
> that the restriction only applies when Clavis is not enabled?  You don't 
> think there would be push back that those restrictions are not always 
> being enforced?

Instead I would add a Kconfig "Note:" indicating that enabling Clavis relaxes
the requirement that the key exists on the system trusted
.secondary_trusted_keys keyring.

thanks,

Mimi