> 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). 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?
