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.
--
paul-moore.com
