On Wed, Oct 23, 2024 at 07:25:21PM +0000, Eric Snowberg wrote: > > On Oct 22, 2024, at 8:25 PM, ser...@kernel.org wrote: > > > > On Thu, Oct 17, 2024 at 09:55:11AM -0600, Eric Snowberg wrote: > >> > >> +The Clavis LSM contains a system keyring call .clavis. It contains a > >> single > > > > s/call/called/ > > I will change that, thanks. > > >> +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? > > In the case where Clavis was not provided a key id during boot, root can > add a single public key to the .clavis keyring anytime afterwards. This > key does not need to be in any of the system keyrings. Once the key is > added, the Clavis LSM is enabled. The root user must also own the private > key, since this is required to do the ACL signing. I will try to clarify this > better
Ooh, I see. Own it as in be able to sign things with it. Of course. Thanks. > in the documentation. > > I wouldn't expect this to be the typical way Clavis would be used. I would Right, I wasn't asking because I would want to use it that way, but because it feels potentially dangerous :) > also be interested in any feedback if enabling the Clavis LSM this way > following boot should be removed. If this were removed, Clavis could > only be enabled when using the boot parameter. Yeah I don't know enough to give good guidance here. I do worry about UKIs enforcing only the built-in signed kernel command line and so preventing a user from appending their own clavis= entry. Not knowing how this will end up getting deployed, I'm not sure which is the more important issue. > > And this is done by simply loading it into the clavis keyring, right? > > Correct. >
