> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: >>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: >>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: >>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: >>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>>>>>>>> >>>>>>>>> I'd still also like to see some discussion about moving towards the >>>>>>>>> addition of keyrings oriented towards usage instead of limiting >>>>>>>>> ourselves to keyrings that are oriented on the source of the keys. >>>>>>>>> Perhaps I'm missing some important detail which makes this >>>>>>>>> impractical, but it seems like an obvious improvement to me and would >>>>>>>>> go a long way towards solving some of the problems that we typically >>>>>>>>> see with kernel keys. >>>>>> >>>>>> The intent is not to limit ourselves to the source of the key. The main >>>>>> point of Clavis is to allow the end-user to determine what kernel keys >>>>>> they want to trust and for what purpose, irrespective of the originating >>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could >>>>>> go back in time, individual keyrings could be created that are oriented >>>>>> toward usage. The idea for introducing Clavis is to bridge what we >>>>>> have today with kernel keys and allow them to be usage based. >>>>> >>>>> While it is unlikely that the current well known keyrings could be >>>>> removed, I see no reason why new usage oriented keyrings could not be >>>>> introduced. We've seen far more significant shifts in the kernel over >>>>> the years. >>>> >>>> Could you further clarify how a usage oriented keyring would work? For >>>> example, if a kernel module keyring was added, how would the end-user >>>> add keys to it while maintaining a root of trust? >>> >>> Consider it an exercise left to the reader :) >>> >>> I imagine there are different ways one could do that, either using >>> traditional user/group/capability permissions and/or LSM permissions, >>> it would depend on the environment and the security goals of the >>> overall system. >> >> These keys are used by the Lockdown LSM to provide signature >> validation. >> >> I realize the contents that follow in this paragraph is outside the >> boundary of mainline kernel code. Every distro that wants their >> shim signed must explain how their kernel enforces lockdown >> mode. The minimum requirement is lockdown in integrity mode. >> Also, the expectation is lockdown enforcement continues on >> through a kexec. > > I personally find it very amusing the UEFI Secure Boot shim is reliant > on an unmaintained and only marginally supported LSM, Lockdown. Has > anyone recently verified that Lockdown's protections are still intact > and comprehensive enough to be worthwhile? Sorry, this is a bit of a > digression, but since you were the one to bring up Lockdown I thought > it would be important to mention that I don't have much faith that it > is still working to the same level as it originally was intended. I > have a TODO list item to draft a policy around deprecating > unmaintained LSMs after an extended period of time, and once that is > in place if we don't have a qualified maintainer for Lockdown it will > likely fall into the deprecation process (whatever that may be). Does this mean Microsoft will begin signing shims in the future without the lockdown requirement?
