From: sergeh@kernel.org
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: linux-security-module@vger.kernel.org, dhowells@redhat.com,
dwmw2@infradead.org, herbert@gondor.apana.org.au,
davem@davemloft.net, ardb@kernel.org, jarkko@kernel.org,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
zohar@linux.ibm.com, roberto.sassu@huawei.com,
dmitry.kasatkin@gmail.com, mic@digikod.net,
casey@schaufler-ca.com, stefanb@linux.ibm.com,
ebiggers@kernel.org, rdunlap@infradead.org,
linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-efi@vger.kernel.org,
linux-integrity@vger.kernel.org
Subject: Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis
Date: Wed, 23 Oct 2024 02:25:56 +0000 [thread overview]
Message-ID: <ZxhetCy5RE1k4_Jk@lei> (raw)
In-Reply-To: <20241017155516.2582369-9-eric.snowberg@oracle.com>
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@oracle.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
next prev parent reply other threads:[~2024-10-23 2:26 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:55 [RFC PATCH v3 00/13] Clavis LSM Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check Eric Snowberg
2024-10-17 16:13 ` Jarkko Sakkinen
2024-10-17 16:50 ` Eric Snowberg
2024-12-23 13:21 ` Mimi Zohar
2025-01-03 23:15 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key Eric Snowberg
2024-10-17 16:16 ` Jarkko Sakkinen
2024-10-17 16:53 ` Eric Snowberg
2024-12-23 16:11 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis Eric Snowberg
2024-10-17 16:50 ` Jarkko Sakkinen
2024-10-17 20:34 ` Eric Snowberg
2024-10-17 21:16 ` Jarkko Sakkinen
2024-12-24 0:01 ` Mimi Zohar
2025-01-03 23:27 ` Eric Snowberg
2025-01-05 11:43 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) Eric Snowberg
2024-10-17 19:20 ` Jarkko Sakkinen
2024-10-17 21:42 ` Eric Snowberg
2024-10-17 21:58 ` Jarkko Sakkinen
2024-12-24 0:17 ` Mimi Zohar
2025-01-03 23:28 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl Eric Snowberg
2024-10-18 5:21 ` Ben Boeckel
2024-10-18 15:42 ` Eric Snowberg
2024-10-18 16:55 ` Ben Boeckel
2024-10-18 21:55 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature Eric Snowberg
2024-10-17 19:27 ` Jarkko Sakkinen
2024-10-17 15:55 ` [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key Eric Snowberg
2025-02-06 20:13 ` Jarkko Sakkinen
2025-02-07 23:09 ` Eric Snowberg
2025-02-12 12:42 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis Eric Snowberg
2024-10-23 2:25 ` sergeh [this message]
2024-10-23 19:25 ` Eric Snowberg
2024-10-24 19:57 ` sergeh
2024-12-24 17:43 ` Mimi Zohar
2025-01-03 23:32 ` Eric Snowberg
2025-01-05 12:59 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 09/13] clavis: Allow user to define acl at build time Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 10/13] efi: Make clavis boot param persist across kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 11/13] clavis: Prevent boot param change during kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 12/13] clavis: Add function redirection for Kunit support Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 13/13] clavis: " Eric Snowberg
2024-12-24 1:11 ` Mimi Zohar
2024-12-23 12:09 ` [RFC PATCH v3 00/13] Clavis LSM Mimi Zohar
2025-01-03 23:14 ` Eric Snowberg
2025-01-04 4:48 ` Paul Moore
2025-01-06 3:40 ` Paul Moore
2025-01-06 17:15 ` Eric Snowberg
2025-02-27 20:41 ` Mimi Zohar
2025-02-27 22:22 ` Paul Moore
2025-02-28 14:08 ` Mimi Zohar
2025-02-28 16:14 ` Paul Moore
2025-02-28 17:18 ` Mimi Zohar
2025-03-03 22:38 ` Paul Moore
2025-03-04 12:53 ` Mimi Zohar
2025-03-05 0:19 ` Paul Moore
2025-03-05 1:49 ` Mimi Zohar
2025-03-05 2:09 ` Paul Moore
2025-03-05 2:20 ` Mimi Zohar
2025-03-05 2:24 ` Paul Moore
2025-02-28 17:51 ` Eric Snowberg
2025-03-03 22:40 ` Paul Moore
2025-03-04 14:46 ` Eric Snowberg
2025-03-05 0:23 ` Paul Moore
2025-03-05 21:29 ` Eric Snowberg
2025-03-06 1:12 ` Paul Moore
2025-03-06 22:28 ` Eric Snowberg
2025-03-07 2:46 ` Paul Moore
2025-03-20 16:24 ` Eric Snowberg
2025-03-20 21:36 ` Paul Moore
2025-03-21 16:37 ` Eric Snowberg
2025-03-21 18:57 ` Paul Moore
2025-03-21 21:20 ` Eric Snowberg
2025-03-21 22:13 ` Paul Moore
2025-03-21 22:56 ` Eric Snowberg
2025-03-22 2:00 ` Paul Moore
2025-03-21 17:22 ` Jarkko Sakkinen
2025-03-21 19:05 ` Paul Moore
2025-03-20 22:40 ` James Bottomley
2025-03-21 16:40 ` Eric Snowberg
2025-03-21 16:55 ` James Bottomley
2025-03-21 20:15 ` Eric Snowberg
2025-03-21 20:53 ` James Bottomley
2025-03-24 17:44 ` Eric Snowberg
2025-03-21 17:08 ` Jarkko Sakkinen
2025-03-04 22:24 ` Jarkko Sakkinen
2025-03-05 0:25 ` Paul Moore
2025-03-05 0:29 ` Jarkko Sakkinen
2025-03-01 2:20 ` Jarkko Sakkinen
2025-03-01 2:19 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZxhetCy5RE1k4_Jk@lei \
--to=sergeh@kernel.org \
--cc=ardb@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).