[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