[RFC PATCH v2 0/8] Clavis LSM

[Eric Snowberg]

> On Jun 19, 2024, at 9:22 AM, Mimi Zohar <zohar at linux.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.