Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall

[John Johansen]

On 5/6/25 23:26, Song Liu wrote:
> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
> <maxime.belair@xxxxxxxxxxxxx> 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