On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: > > 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: ... > >> 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. I want to address two things, the first, and most important, is that while I am currently employed by Microsoft, I do not speak for Microsoft and the decisions and actions I take as an upstream Linux kernel maintainer are not vetted by Microsoft in any way. I think you will find that many upstream kernel maintainers operate in a similar way for a variety of very good reasons. The second issue is that my main focus is on ensuring we have a secure, safe, and well maintained LSM subsystem within the upstream Linux kernel. While I do care about downstream efforts, e.g. UEFI Secure Boot, those efforts are largely outside the scope of the upstream Linux kernel and not my first concern. If the developer groups who are focused on things like UEFI SB want to rely on functionality within the upstream Linux kernel they should be prepared to stand up and contribute/maintain those features or else they may go away at some point in the future. In very blunt terms, contribute upstream or Lockdown dies. However, let me be clear that I consider deprecation and removal of a LSM to be an option of last resort. My preference would be to find a capable maintainer, or two, that would be willing to take on a maintenance role for the LSM in question. Luckily I think we may have some people who are interested in doing so for the Lockdown LSM, hopefully you'll see something on-list in the near future. > The alternative "usage-oriented keyring" approach you've suggested > wouldn't align with the threat model that lockdown aims to achieve. That's a Lockdown problem, or more specifically a problem for the people who are freeloading on the Lockdown LSM and expecting it to be maintained without contributing anything meaningful. > For > a distro-based kernel, I don't see the value in pursuing such an approach. So you've said. I disagree, but we've already had that discussion, let's agree to not waste any more time repeating ourselves. > 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. As mentioned previously, the design/implementation choices you made for Clavis means it is better suited for inclusion in the key subsystem and not as a standalone LSM. If you wanted to redesign/rework Clavis to stick to the traditional LSM security blobs perhaps that is something we could consider as a LSM, but it's probably worth seeing if David and Jarkko have any interest in including Clavis functionality in the key subsystem first. -- paul-moore.com
