On Fri, 2025-01-03 at 23:32 +0000, Eric Snowberg wrote: > > > On Dec 24, 2024, at 10:43 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> 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@xxxxxxxxxx> > > > --- > > > 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
