On Wed, 23 Oct 2024 at 00:45, <luca.boccassi@xxxxxxxxx> wrote: > > On Sat, 5 Oct 2024 at 17:06, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Fri, Oct 4, 2024 at 2:48 PM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote: > > > On Wed, 2 Oct 2024 at 15:48, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Wed, Oct 2, 2024 at 10:25 AM <luca.boccassi@xxxxxxxxx> wrote: > > > > ... > > > > > > [NOTE: please CC the LSM list on changes like this] > > > > > > > > Thanks Luca :) > > > > > > > > With the addition of the LSM syscalls we've created a lsm_ctx struct > > > > (see include/uapi/linux/lsm.h) that properly supports multiple LSMs. > > > > The original char ptr "secctx" approach worked back when only a single > > > > LSM was supported at any given time, but now that multiple LSMs are > > > > supported we need something richer, and it would be good to use this > > > > new struct in any new userspace API. > > > > > > > > See the lsm_get_self_attr(2) syscall for an example (defined in > > > > security/lsm_syscalls.c but effectively implemented via > > > > security_getselfattr() in security/security.c). > > > > > > Thanks for the review, makes sense to me - I had a look at those > > > examples but unfortunately it is getting a bit beyond my (very low) > > > kernel skills, so I've dropped the string-based security_context from > > > v2 but without adding something else, is there someone more familiar > > > with the LSM world that could help implementing that side? > > > > We are running a little short on devs/time in LSM land right now so I > > guess I'm the only real option (not that I have any time, but you know > > how it goes). If you can put together the ioctl side of things I can > > likely put together the LSM side fairly quickly - sound good? > > Here's a skeleton ioctl, needs lsm-specific fields to be added to the new struct, and filled in the new function: Forgot to mention, this is based on the vfs.pidfs branch of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
