Message-ID: <6DDCFABC-8440-4316-98D4-E3F5C9532925@oracle.com>
Date: Fri, 3 Jan 2025 23:32:16 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Mimi Zohar <zohar@...ux.ibm.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 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).

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?

Powered by blists - more mailing lists