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