linux-kernel - Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZxhetCy5RE1k4_Jk@lei>
Date: Wed, 23 Oct 2024 02:25:56 +0000
From: sergeh@...nel.org
To: Eric Snowberg <eric.snowberg@...cle.com>
Cc: linux-security-module@...r.kernel.org, dhowells@...hat.com,
	dwmw2@...radead.org, herbert@...dor.apana.org.au,
	davem@...emloft.net, ardb@...nel.org, jarkko@...nel.org,
	paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
	zohar@...ux.ibm.com, roberto.sassu@...wei.com,
	dmitry.kasatkin@...il.com, mic@...ikod.net, casey@...aufler-ca.com,
	stefanb@...ux.ibm.com, ebiggers@...nel.org, rdunlap@...radead.org,
	linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
	linux-crypto@...r.kernel.org, linux-efi@...r.kernel.org,
	linux-integrity@...r.kernel.org
Subject: Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

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@...cle.com>
> ---
>  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