[RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul at paul-moore.com> wrote:
> 
> On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg at oracle.com> wrote:
>>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul at paul-moore.com> wrote:
>>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg at oracle.com> wrote:
>>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul at paul-moore.com> wrote:
>>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg at oracle.com> wrote:
>>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul at paul-moore.com> wrote:
>>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar at linux.ibm.com> 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?