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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9b6fd06e-5438-4539-821c-6f3d5fa6b7d1@suse.com>
Date: Tue, 29 Jul 2025 15:25:58 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
 paul@...l-moore.com, serge@...lyn.com, jmorris@...ei.org,
 dan.j.williams@...el.com
Subject: Re: [PATCH v2 0/3] Allow individual features to be locked down



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>