Re: [RFC PATCH v3 00/13] Clavis LSM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Mar 20, 2025, at 3:36 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> 
> 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.

...

> 
>> 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.  





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux