On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > Motivation: > > Each end-user has their own security threat model. What is important to one > end-user may not be important to another. There is not a right or wrong threat > model. > > A common request made when adding new kernel changes that could impact the > threat model around system kernel keys is to add additional Kconfig options. > As kernel developers, it is challenging to both add and keep track of all the > Kconfig options around security features that may limit or restrict > system key usage. It is also difficult for a general purpose distro to take > advantage of some of these features, since it may prevent some users from > executing their workload. > > It is the author's belief that it is better left up to the end-user on how > kernel keys should be used within their system. > > Throughout the Linux kernel, key usage is tracked when doing signature > verification with keys contained within one of the system keyrings; however, > there isn't a way for the end-user to enforce this usage. This series gives the > end-user the ability to configure key usage based on their threat model. > Having the ability to enforce key usage also improves security by reducing the > attack surface should a system key be compromised. It allows new features to be > added without the need for additional Kconfig options for fear of changing the > end-user's threat model. It also allows a distro to build a kernel that suits > various end-user's needs without resorting to selecting Kconfig options with > the least restrictive security options. The motivation for this patch set is convincing and addresses limiting the usage of keys loaded directly or indirectly onto the system trusted keyrings - .builtin, .machine, and .secondary_trusted_keys keyrings. Pre-loading the build time ephemeral kernel module signing key is a nice improvement from the previous versions. My main concern is not with Clavis per-se, but that the LSM infrastructure allows configuring all the LSMs, but enabling at build time and modifying at runtime a subset of them. Without Clavis enabled, nothing changes - any key on the system trusted keyrings remains usable for any purpose. With the current LSM design, the end user security threat model cannot be guaranteed. Mimi > > Solution: > > This series introduces a new LSM called Clavis (Latin word meaning key). > This LSM leaves it up to the end-user to determine what system keys they want > to use and for what purpose. > > The Clavis LSM adds the ability to do access control for all system keys. When > enabled, until an ACL entry is added for a specific key, none of the system keys > may be used for any type of verification purpose. When the kernel is built, > typically kernel modules are signed with an ephemeral key, an ACL entry for the > ephemeral key is pre-loaded, allowing the kernel modules to load during boot. At > build time other ACL entries may also be included. > > The Clavis LSM requires the end-user to have their own public key infrastructure > (PKI). In order for a Clavis ACL entry to be added, the ACL must be signed by > what is being called the Clavis key. The Clavis key is owned by the end-user. > The Clavis public key can be contained within the machine keyring, or it can be > added after the machine boots. > > Not only is there a new Clavis key being introduced, but there is also a new > .clavis keyring. The .clavis keyring contains a single Clavis key. It also > contains any number of ACL entries that are signed by the Clavis key. > > It is believed that the most common setup would be to have the Clavis key > contained within the machine keyring. Enabling the Clavis LSM during boot is > accomplished by passing in the asymmetric key id for the Clavis key within a > new "clavis=" boot param. The asymmetric key id must match one already > contained within any of the system keyrings. If a match is found, a link is > created into the new .clavis keyring. This Clavis key shall be used as the > root of trust for any keyring ACL updates afterwards. > > On UEFI systems the "clavis" boot param is mirrored into a new UEFI variable > within the EFI stub code. This variable will persist until the next reboot. > This same type of functionality is done within shim. Since this variable is > created before ExitBootServices (EBS) it will not have the NVRAM bit set, > signifying it was created during the Boot Services phase. This is being used > so the "clavis" boot param can not be changed via kexec, thereby preventing a > pivot of the root of trust. > > As mentioned earlier, this LSM introduces a new .clavis keyring. Following > boot, no new keys can be added to this keyring and only the key designated via > the initial boot param may be used. If the clavis boot param was not used, the > LSM can be enabled afterwards using the keyctl command. The end-user may add > their Clavis key into the .clavis keyring and the Clavis LSM shall be enabled. > > The .clavis keyring also holds the access control list for system keys. A new > key type called clavis_key_acl is being introduced. This contains the usage > followed by the asymmetric key id. To be added to the clavis keyring, the > clavis_key_acl must be S/MIME signed by the Clavis key. New ACL additions to > the .clavis keyring may be added at any time. > > Currently this LSM does not require new changes or modifications to any user > space tools. It also does not have a securityfs interface. Everything is > done using the existing keyctl tool through the new .clavis keyring. The > S/MIME signing can be done with a simple OpenSSL command. If additions or > updates need to be added in the future, new ACL key types could be created. > With this approach, maintainability should not be an issue in the future > if missing items are identified. > > Clavis must be configured at build time with CONFIG_SECURITY_CLAVIS=y. The list > of security modules enabled by default is set with CONFIG_LSM. The kernel > configuration must contain CONFIG_LSM=[...],clavis with [...] as the list of > other security modules for the running system. > > For setup and usage instructions, a clavis admin-guide has been included > in Documentation/admin-guide/LSM/clavis.rst. > > Future enhancements to this LSM could include: > > 1. Subsystems that currently use system keys with > VERIFYING_UNSPECIFIED_SIGNATURE could be updated with their specific usage > type. For example, a usage type for IMA, BPF, etc could be added. > > 2. Having the ability to allow platform keys to be on par with all other > system keys when using this LSM. This would be useful for a user that > controls their entire UEFI SB DB key chain and doesn't want to use MOK keys. > This could also potentially remove the need for the machine keyring all > together. > > 3. Some of the Kconfig options around key usage and types could be deprecated. > > I would appreciate any feedback on this approach. Thanks. > > Changes in v3: > Rebased to 6.12-rc3 > Added Kunit test code > Preload an ACL in the clavis keyring with the ephemeral module signing key > Preload user defined ACL data into the clavis keyring with build time data > Changes to the second patch recommended by Jarkko > Reordered patches recommended by Mimi > Documentation improvements recommended by Randy > > Changes in v2: > Rebased to 6.10-rc1 > Various cleanup in the first patch recommended by Jarkko > Documentation improvements recommended by Randy > Fixed lint warnings > Other cleanup > > Eric Snowberg (13): > certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check > certs: Introduce ability to link to a system key > clavis: Introduce a new system keyring called clavis > keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) > clavis: Introduce a new key type called clavis_key_acl > clavis: Populate clavis keyring acl with kernel module signature > keys: Add ability to track intended usage of the public key > clavis: Introduce new LSM called clavis > clavis: Allow user to define acl at build time > efi: Make clavis boot param persist across kexec > clavis: Prevent boot param change during kexec > clavis: Add function redirection for Kunit support > clavis: Kunit support > > Documentation/admin-guide/LSM/clavis.rst | 191 ++++++ > .../admin-guide/kernel-parameters.txt | 6 + > MAINTAINERS | 7 + > certs/.gitignore | 1 + > certs/Makefile | 20 + > certs/blacklist.c | 3 + > certs/clavis_module_acl.c | 7 + > certs/system_keyring.c | 36 +- > crypto/asymmetric_keys/asymmetric_type.c | 1 + > crypto/asymmetric_keys/pkcs7_trust.c | 20 + > crypto/asymmetric_keys/pkcs7_verify.c | 5 + > crypto/asymmetric_keys/signature.c | 4 + > drivers/firmware/efi/Kconfig | 12 + > drivers/firmware/efi/libstub/Makefile | 1 + > drivers/firmware/efi/libstub/clavis.c | 33 + > .../firmware/efi/libstub/efi-stub-helper.c | 2 + > drivers/firmware/efi/libstub/efi-stub.c | 2 + > drivers/firmware/efi/libstub/efistub.h | 8 + > drivers/firmware/efi/libstub/x86-stub.c | 2 + > include/crypto/pkcs7.h | 3 + > include/crypto/public_key.h | 4 + > include/keys/system_keyring.h | 7 +- > include/linux/efi.h | 1 + > include/linux/integrity.h | 8 + > include/linux/lsm_count.h | 8 +- > include/linux/lsm_hook_defs.h | 2 + > include/linux/security.h | 7 + > include/linux/verification.h | 2 + > include/uapi/linux/lsm.h | 1 + > security/Kconfig | 11 +- > security/Makefile | 1 + > security/clavis/.gitignore | 2 + > security/clavis/.kunitconfig | 4 + > security/clavis/Kconfig | 37 ++ > security/clavis/Makefile | 156 +++++ > security/clavis/clavis.c | 26 + > security/clavis/clavis.h | 62 ++ > security/clavis/clavis_builtin_acl.c | 7 + > security/clavis/clavis_efi.c | 50 ++ > security/clavis/clavis_keyring.c | 426 +++++++++++++ > security/clavis/clavis_test.c | 566 ++++++++++++++++++ > security/integrity/iint.c | 2 + > security/security.c | 13 + > .../selftests/lsm/lsm_list_modules_test.c | 3 + > 44 files changed, 1757 insertions(+), 13 deletions(-) > create mode 100644 Documentation/admin-guide/LSM/clavis.rst > create mode 100644 certs/clavis_module_acl.c > create mode 100644 drivers/firmware/efi/libstub/clavis.c > create mode 100644 security/clavis/.gitignore > create mode 100644 security/clavis/.kunitconfig > create mode 100644 security/clavis/Kconfig > create mode 100644 security/clavis/Makefile > create mode 100644 security/clavis/clavis.c > create mode 100644 security/clavis/clavis.h > create mode 100644 security/clavis/clavis_builtin_acl.c > create mode 100644 security/clavis/clavis_efi.c > create mode 100644 security/clavis/clavis_keyring.c > create mode 100644 security/clavis/clavis_test.c > > > base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354
