Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook

[John Johansen]

On 5/7/25 03:40, Tetsuo Handa wrote:
> On 2025/05/06 23:32, Maxime Bélair wrote:
> > diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
> > index dcaad8818679..b39e6635a7d5 100644
> > --- a/security/lsm_syscalls.c
> > +++ b/security/lsm_syscalls.c
> > @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
> >   SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
> >   		__user *, size, u32, flags)
> >   {
> > -	return 0;
> > +	size_t usize;
> > +
> > +	if (get_user(usize, size))
> > +		return -EFAULT;
> > +
> > +	return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
> >   }
>
> syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
>
> This interface might be fine for AppArmor, but TOMOYO won't use this interface because
> TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
> pseudo‑filesystem's filename; use of filename helps restricting which type of policy
> can be manipulated by which process.

That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
needs. I look at the current implementation as an opening discussion of what the syscall
should look like. I have no delusions that we are going to get something that will fit
all LSMs but without requirements, we won't be able to even attempt to hash something
better out.