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.

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
-- 
2.45.0

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

Hi Mimi,

> On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> 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.  

Apologies for the delayed response and thanks for your feedback on this 
and the other patches you reviewed in the series.

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

I went in the direction of creating a new LSM based on this discussion [1].  
I was hoping to get some feedback from Paul, since I believe I have 
addressed the guidelines for a new LSM.  Currently, the Clavis LSM only 
adds a single LSM hook.  To address your concern, maybe Clavis shouldn't 
be a LSM?  Possibly it could live in the keyring code on its own.

1. https://lkml.org/lkml/2023/10/5/312

On Fri, Jan 3, 2025 at 6:14 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:

...

> > 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.
>
> I went in the direction of creating a new LSM based on this discussion [1].
> I was hoping to get some feedback from Paul, since I believe I have
> addressed the guidelines for a new LSM.  Currently, the Clavis LSM only
> adds a single LSM hook.  To address your concern, maybe Clavis shouldn't
> be a LSM?  Possibly it could live in the keyring code on its own.

My turn to apologize for a very late reply, you've been very patient
and I appreciate that.

With respect to Mimi's concerns about disabling Clavis, or any LSM for
that matter, at runtime, doing so requires the ability to modify the
kernel's command line.  I would argue that if a user can manipulate
the kernel command line there are more serious issues that need to be
dealt with first.  Any user who is seriously concerned about the state
of their system should have some mechanism in place to ensure that the
kernel command line is not subject to tampering; thankfully there are
efforts underway to help bring tamper resistant command lines to a
larger audience (the UKI work).

I can't remember if anyone has ever brought this up on-list, and if so
what objections there may have been, but I've always wondered if the
real problem is simply that we use a handful of keyrings for far too
many things inside the kernel.  What terrible things would need to be
overcome if we created additional keyrings based on usage, e.g.
".modulesigning", and used these task specific keyrings instead of the
existing source/trust oriented keyrings?  I imagine we would likely
need some mechanism to link a key from the existing source/trust
keyrings, e.g. ".machine", to a task specific keyring, e.g.
".modulesigning", but I can't imagine that would be too difficult.

Regardless, back to Clavis ... reading quickly through the cover
letter again, I do somewhat wonder if this isn't better integrated
into the keyring proper; have you talked to both David and Jarkko
about this?  Were they supportive of the idea, but simply felt it was
better as an LSM?  I see Jarkko has reviewed and commented on a number
of the patches, so I'll take that as an implicit acceptance of the
concept, but have you heard anything from David?

-- 
paul-moore.com

On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
>
> Regardless, back to Clavis ... reading quickly through the cover
> letter again, I do somewhat wonder if this isn't better integrated
> into the keyring proper; have you talked to both David and Jarkko
> about this?

I realize I should probably expand on my thinking a bit, especially
since my comment a while regarding LSMs dedicated to enforcing access
control on keys is what was given as a reason for making Clavis a LSM.

I still stand by my comment from over a year ago that I see no reason
why we couldn't support a LSM that enforces access controls on
keyrings/keys.  What gives me pause with the Clavis LSM is that so
much of Clavis is resident in the keyrings themselves, e.g. Clavis
policy ACLs and authorization keys, that it really feels like it
should be part of the keys subsystem and not a LSM.  Yes, existing
LSMs do have LSM specific data that resides outside of the LSM and in
an object's subsystem, but that is usually limited to security
identifiers and similar things, not the LSM's security policy.

That's my current thinking, and why I asked about locating Clavis in
the keys subsystem directly (although I still think better keyring
granularity and a shift towards usage based keyrings is the better
option).  If David and Jarkko are opposed to integrating Clavis into
the keys subsystem we can consider this as a LSM, I'm just not sure
it's the best first option.  Does that make sense?

-- 
paul-moore.com