[RFC PATCH v3 00/13] Clavis LSM
Eric Snowberg
eric.snowberg at oracle.com
Fri Mar 21 16:37:15 UTC 2025
> On Mar 20, 2025, at 3:36 PM, Paul Moore <paul at paul-moore.com> wrote:
>
> On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg at oracle.com> wrote:
>>> On Mar 6, 2025, at 7:46 PM, Paul Moore <paul at paul-moore.com> wrote:
>>> On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg at oracle.com> 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.
...
>
>> 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.
There are past examples of previous contributions, but they don't seem to
go anywhere:
https://lkml.org/lkml/2023/5/26/1057
Which causes us to carry patches like this downstream.
>
>> 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.
The direction of creating a new LSM was based on this discussion:
https://lkml.org/lkml/2023/10/5/312
A lot of time could have been saved had your concerns been
voiced in either the first or second round. If David or Jarkko are
interested in a non LSM version, I can work on that.
More information about the Linux-security-module-archive
mailing list