linux-kernel - Re: [PATCH 1/3] Wire up the lsm_manage

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: <48b5512b-5e38-405a-80e7-64be43bf04e8@canonical.com>
Date: Thu, 8 May 2025 00:12:58 -0700
From: John Johansen <john.johansen@...onical.com>
To: Song Liu <song@...nel.org>, Maxime Bélair
 <maxime.belair@...onical.com>
Cc: linux-security-module@...r.kernel.org, paul@...l-moore.com,
 jmorris@...ei.org, serge@...lyn.com, mic@...ikod.net, kees@...nel.org,
 stephen.smalley.work@...il.com, casey@...aufler-ca.com,
 takedakn@...data.co.jp, penguin-kernel@...ove.sakura.ne.jp,
 linux-api@...r.kernel.org, apparmor@...ts.ubuntu.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall

On 5/6/25 23:26, Song Liu wrote:
> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
> <maxime.belair@...onical.com> wrote:
>>
>> Add support for the new lsm_manage_policy syscall, providing a unified
>> API for loading and modifying LSM policies without requiring the LSM’s
>> pseudo-filesystem.
>>
>> Benefits:
>>    - Works even if the LSM pseudo-filesystem isn’t mounted or available
>>      (e.g. in containers)
>>    - Offers a logical and unified interface rather than multiple
>>      heterogeneous pseudo-filesystems.
> 
> These two do not feel like real benefits:
> - Not working in containers is often not an issue, but a feature.

and the LSM doesn't have to allow the syscall to function in a container
where appropriate. Its up to the LSM if the syscall is supported and
what kind of permissions are needed.

However having the ability to function in a container and not having to
mount securityfs, or procfs into a container. similar to what landlock
gets with its syscall can be beneficial.

> - One syscall cannot fit all use cases well...
> 
of course not, and for those other use cases new syscalls can be added.

>>    - Avoids overhead of other kernel interfaces for better efficiency
> 
> .. and it is is probably less efficient, because everything need to
> fit in the same API.
> 
no not everything, just what fits into the syscall. Nor does an LSM
have to use the syscall it is still use what works for it.

This could be a little more efficient than the current fs interface
used by apparmor/selinux/smack but I don't think efficiency is going
to be a huge win for this.


> Overall, this set doesn't feel like a good change to me.
> 
> Thanks,
> Song