LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/9/2022 9:17 PM, Tetsuo Handa wrote:
> On 2022/09/09 7:56, Casey Schaufler wrote:
>> Good idea. I'm reading the official how-to-write-a-syscall documentation.
> Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
> is loaded, and pass that LSM ID as one of arguments for prctl().

I'm not the fan of an LSM ID that Paul is, but if we're going to use them I much
prefer a static value to a dynamic one. Libraries/programs that have to query the
system to get the ID ( int selinuxid = lsm_get_id("selinux"); ) are harder to
maintain. It would really push us toward requiring a liblsm, which I think we're
still trying to avoid.

That doesn't give us a good answer for loadable modules. The last time I looked
seriously at loadable modules I was considering that we'd need a security module
that manages them, very much like BPF manages the eBPF programs. Loadable modules
could use prctl, or some other mechanism, but they would have to be different
from built-in modules. You can't require built-in modules to conform to the
restrictions you'd have to impose on loadable ones. The Loadable Module Security
Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I think it could be made to work. I can't say that it is something I am likely to
get to soon.

>
> Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM 
> which was assigned that LSM ID upon load checks arguments (including PID argument).
> That will be something like ioctl() without open("/proc/pid/*/attr/*").
>