> On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: >>> 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? > > That's not a question I can answer, you'll need to discuss that with the UEFI SB people. Based on your previous lockdown comments, I thought you might have some new information. Having lockdown enforcement has always been a requirement to get a shim signed by Microsoft. The alternative "usage-oriented keyring" approach you've suggested wouldn't align with the threat model that lockdown aims to achieve. For a distro-based kernel, I don't see the value in pursuing such an approach. For someone compiling their own kernel and not using a distro kernel, they could compile in their own keys. With Clavis, I attempted to develop an approach that would meet the lockdown threat model requirements while allowing the end user to control key usage as they deem fit.
