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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <kl4rvgnupxnz4zrwlofrawdfy23tj2ylp5s3wovnsjxkr6tbrt@x5s3avqo2e7t>
Date: Tue, 29 Jul 2025 14:16:53 +0200
From: Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>
To: Nikolay Borisov <nik.borisov@...e.com>
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

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 ?

[1]: https://lore.kernel.org/all/CAGXu5j+UWQWDacMvvRCke3xUOb7uTkxn=WaHzG4kJTKWh-6tAA@mail.gmail.com/

Best regards,

Nicolas

---

On Mon, Jul 28, 2025 at 02:15:14PM +0300, Nikolay Borisov wrote:
> This simple change allows usecases where someone might want to  lock only specific
> feature at a finer granularity than integrity/confidentiality levels allows.
> The first likely user of this is the CoCo subsystem where certain features will be
> disabled.
> 
> Changes since v1:
>  * Added Patch 3 to incoroporate Serge's hardening suggestion
> 
> Nikolay Borisov (3):
>   lockdown: Switch implementation to using bitmap
>   lockdown/kunit: Introduce kunit tests
>   lockdown: Use snprintf in lockdown_read
> 
>  security/lockdown/Kconfig         |  5 +++
>  security/lockdown/Makefile        |  1 +
>  security/lockdown/lockdown.c      | 36 +++++++++++++++------
>  security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
>  4 files changed, 86 insertions(+), 10 deletions(-)
>  create mode 100644 security/lockdown/lockdown_test.c
> 
> --
> 2.34.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ