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: <42b2cf1b-417e-1594-d525-f4c84f7405b0@huawei.com>
Date: Tue, 5 Aug 2025 14:57:23 +0800
From: xiujianfeng <xiujianfeng@...wei.com>
To: Nikolay Borisov <nik.borisov@...e.com>, 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 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.

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