Dominick, > From: Dominick Grift <dominick.grift@xxxxxxxxxxx> > Sent: Tuesday, August 3, 2021 12:22 PM > To: Weber, Matthew L Collins <Matthew.Weber@xxxxxxxxxxx> > Cc: selinux@xxxxxxxxxxxxxxx <selinux@xxxxxxxxxxxxxxx>; linux-security-module@xxxxxxxxxxxxxxx <linux-security-module@xxxxxxxxxxxxxxx>; Graziano, > David D Collins <david.graziano@xxxxxxxxxxx> > Subject: [External] Re: LSM policy options for new GPIO kernel driver interface > [snip] > > SELinux supports IOCTL allow-listing and so access to the various GPIO > IOCTL can probably already be controlled. > We had been looking at this option but noticed the GPIO are broken out in groups by the "chip" providing them so a granular single IO "write" action can't be controlled through an allow-listing. One idea we were going to look into was to break out all the IO in a chip as minor dev nodes which then could have specific IOCTL controls applied. The default policy could restrict the "chip" node and then have broken out rules for each minor IO. > Other than that you could consider adding LSM hooks for GPIO object > related syscalls and adding SELinux check for GPIO syscall operations > but not sure if that adds any value to the above. Assuming you're referring to something like SECCOMP filtering the IOCTL, that would shift the responsibility to userspace to properly use the SECCOMP filter... Or are you referring to new hooks on the kernel side of the syscall handling that would partially decode the payload of the call? Thanks for the response on this. I wanted to have some debate before reaching out to the GPIO maintainers to look at options from their perspective. Best Regards, Matt
