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

Nikolay Borisov nik.borisov at suse.com
Tue Jul 29 12:25:58 UTC 2025



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.


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



More information about the Linux-security-module-archive mailing list