[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <E82A5B50-7F88-4352-B08F-181536BFA66B@oracle.com>
Date: Thu, 20 Jun 2024 20:18:26 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
CC: "open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
David Howells <dhowells@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"davem@...emloft.net" <davem@...emloft.net>,
Ard Biesheuvel
<ardb@...nel.org>, Jarkko Sakkinen <jarkko@...nel.org>,
Paul Moore
<paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn"
<serge@...lyn.com>,
Roberto Sassu <roberto.sassu@...wei.com>,
Dmitry Kasatkin
<dmitry.kasatkin@...il.com>,
Mickaël Salaün
<mic@...ikod.net>,
"casey@...aufler-ca.com" <casey@...aufler-ca.com>,
Stefan
Berger <stefanb@...ux.ibm.com>,
"ebiggers@...nel.org" <ebiggers@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
open list
<linux-kernel@...r.kernel.org>,
"keyrings@...r.kernel.org"
<keyrings@...r.kernel.org>,
"linux-crypto@...r.kernel.org"
<linux-crypto@...r.kernel.org>,
"linux-efi@...r.kernel.org"
<linux-efi@...r.kernel.org>,
"linux-integrity@...r.kernel.org"
<linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH v2 0/8] Clavis LSM
> On Jun 19, 2024, at 9:22 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
>
> On Thu, 2024-05-30 at 18:39 -0600, Eric Snowberg wrote:
>> Introduce a new LSM called Clavis (Latin word meaning key). The motivation
>> behind this LSM is to provide access control for system keys. Before spending
>> more time on this LSM, I am sending this as an RFC to start a discussion to see
>> if the current direction taken has a possibility of being accepted in the
>> future.
>>
>> Today the kernel has the following system keyrings: .builtin_trusted_keyring,
>> .secondary_trusted_keyring, and the .machine. It also has the .platform
>> keyring which has limited capabilities; it can only be used to verify a kernel
>> for kexec.
>
> Please start the cover letter with the problem description/motivation, not the
> solution.
>
> From https://docs.kernel.org/process/submitting-patches.html:
>
> "Describe your problem. Whether your patch is a one-line bug fix or 5000 lines
> of a new feature, there must be an underlying problem that motivated you to do
> this work. Convince the reviewer that there is a problem worth fixing and that
> it makes sense for them to read past the first paragraph."
>
> For example,
>
> Additional keys not built into the kernel could originally be loaded onto the
> .secondary_trusted_keyring *only* if they were signed by a key built into the
> kernel or by a key already on the .secondary_trusted_keyring. The concern for
> using the wrong key for signature verification was minimal. With the ability of
> loading Machine Owner Keys(MOK) keys onto the .machine keyring, which is linked
> to the .secondary_trusted_keys keyring, key usage is a real concern.
>
> To limit key usage ...
I'll change this in the next version.
>>
>> Today the kernel also tracks key usage for verification done with any of these
>> keys. Current verification usage includes: VERIFYING_MODULE_SIGNATURE,
>> VERIFYING_FIRMWARE_SIGNATURE, VERIFYING_KEXEC_PE_SIGNATURE,
>> VERIFYING_KEY_SIGNATURE, VERIFYING_KEY_SELF_SIGNATURE, and
>> VERIFYING_UNSPECIFIED_SIGNATURE. After these usage types were originally
>> introduced, most additions have typically used the
>> VERIFYING_UNSPECIFIED_SIGNATURE.
>>
>> At the moment, besides the usage enforcement for .platform keys, any key
>> contained within the system keyrings can be used for any verification
>> purpose. For example, a key that was originally created to sign kernel
>> modules could be used for BPF verification.
>>
>> This new LSM adds the ability to do access control for all system keys. When
>> enabled, only the .builtin_trusted_keys are available for loading kernel
>> modules and doing a kexec. Until an ACL entry is added for a specific key, no
>> other system key may be used for any other purpose.
>
> Keys stored on the .builtin_trusted_keys keyring seem to always be permitted,
> independent of a Clavis rule, which is fine, but the above paragraph needs to be
> re-worded
And this too.
>>
>> Enabling the LSM is done during initial boot by passing in a single asymmetric
>> key id 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 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 power on
>> reset. 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.
>
> Move this paragraph (and patch) to later. Defining a new UEFI variable makes it
> more difficult to test. Consider defering introducing the new UEFI variable
> patch to the end.
I'll move it to the end to help with testing.
>>
>> As mentioned earlier, this LSM introduces a new .clavis keyring. Following
>> boot, no new asymmetric keys can be added to this keyring and only the key
>> designated via the initial boot param may be used. This LSM can not be started
>> at any other point in time. 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 sole asymmetric
>> key contained within it. New ACL additions to the .clavis keyring may be added
>> at any time.
>
> Ok. To summarize, the Clavis policy rules are loaded at runtime onto the .clavis
> keyring. The Clavis rules must be signed by the key specified on the "clavis="
> boot command line. The only key on the .clavis keyring is the one specified on
> the boot command line.
>
> As far as I'm aware, this would be the first time policy rules are stored in a
> keyring.
I believe that is the case, and would like to hear if this could be a potentially
acceptable solution. It simplifies things in many aspects. It has fewer dependancies,
current user-space tools work with it already, everything is self contained within this
keyring, etc.
Thanks for your feedback.
Powered by blists - more mailing lists