Re: [PATCH v2 0/3] Allow individual features to be locked down

[Nikolay Borisov <nik.borisov@suse.com>]

On 8/5/25 09:57, xiujianfeng wrote:
> 
> 
> On 2025/7/29 20:25, Nikolay Borisov wrote:
>>
>>
>> On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
>>> Hi Nikolay,
>>>
>>> Thanks for you patch.
>>>
>>> Quoting Kees [1], Lockdown is "about creating a bright line between
>>> uid-0 and ring-0".
>>>
>>> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
>>> be activated independently. I fear this would lead to a false sense of
>>> security, locking one reason alone often permits Lockdown restrictions
>>> bypass. i.e enforcing kernel module signature verification but not
>>> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
>>> used to disable the module signature enforcement.
>>>
>>> If one wants to restrict accesses to `/dev/mem`,
>>> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
>>>
>>> My understanding of your problem is that this locks too much for your
>>> usecase and you want to restrict reasons of Lockdown independently in
>>> case it has not been enabled in "integrity" mode by default ?
>>>
>>> Can you elaborate more on the usecases for COCO ?
>>
>> Initially this patchset was supposed to allow us selectively disable
>> /dev/iomem access in a CoCo context [0]. As evident from Dan's initial
>> response that point pretty much became moot as the issue was fixed in a
>> different way. However, later [1] he came back and said that actually
>> this patch could be useful in a similar context. So This v2 is
>> essentially following up on that.
> 
> Hi Nikolay,
> 
> I share a similar view with Nicolas, namely that using a bitmap
> implementation would compromise the goal of Lockdown.
> 
> After reading the threads below, I understand you aim is to block user
> access to /dev/mem, but without having Lockdown integrity mode enabled
> to block other reasons, right? How about using BPF LSM? It seems it
> could address your requirements.
> 

Well the use case that my change allows  (barring the original issue) is 
say if someone wants LOCKDOWN_INTEGRITY_MAX + 1 or 2 things from the 
CONFIDENTIALY_MAX level.

>>
>>
>> [0]
>> https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> [1]
>> https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> <snip>