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/*").
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
