On 8/5/25 09:57, xiujianfeng wrote:
On 2025/7/29 20:25, Nikolay Borisov wrote:
quoted
On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
quoted
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.
quoted
[0]
https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/ (local)
[1]
https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/ (local)
<snip>