On Thu, Oct 17, 2024 at 09:55:11AM -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. > + > +On UEFI platforms, the root of trust key shall survive a kexec. Trying to > +defeat or change it from the command line is not allowed. The original boot > +parameter is stored in UEFI and will always be referenced following a kexec. Does this mean someone can reboot the host, boot another OS, store a key id in UEFI, and force the root of trust key to be one other than what the user lists in clavis= boot argument? Never mind! Saw the answer in patches 10 and 11, thanks. > +The Clavis LSM contains a system keyring call .clavis. It contains a single s/call/called/ > +asymmetric key that is used to validate anything added to it. This key can > +be added during boot and must be a preexisting system kernel key. If the > +``clavis=`` boot parameter is not used, any asymmetric key the user owns Who is "the user", and precisely what does "owns' mean here? Is it just restating that it must be a key already in one of the builtin or secondary or platform keyrings? And this is done by simply loading it into the clavis keyring, right? -serge
