[External] Re: LSM policy options for new GPIO kernel driver interface

[Stephen Smalley]

On Tue, Aug 3, 2021 at 3:17 PM Weber, Matthew L Collins
<Matthew.Weber at collins.com> wrote:
>
> Dominick,
>
> > From: Dominick Grift <dominick.grift at defensec.nl>
> > Sent: Tuesday, August 3, 2021 12:22 PM
> > To: Weber, Matthew L Collins <Matthew.Weber at collins.com>
> > Cc: selinux at vger.kernel.org <selinux at vger.kernel.org>; linux-security-module at vger.kernel.org <linux-security-module at vger.kernel.org>; Graziano, > David D Collins <david.graziano at collins.com>
> > 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.

Circa Linux 4.3, the SELinux kernel code was augmented to support
"extended permissions" with ioctl commands as the initial use case for
Android device driver whitelisting. This is supported in kernel policy
version 30 and later. A simple example can be found in the
selinux-testsuite under the ioctl test. See:
https://blog.siphos.be/2017/11/selinux-and-extended-permissions/
https://selinuxproject.org/page/XpermRules

This may still not provide you with the desired granularity. Depending
on the driver implementation, it may be possible to automatically
transition different "objects" managed by the driver into different
contexts through the recent SELinux anonymous inode labeling support
merged in Linux 5.12. There is an example of this for userfaultfd
inodes in the selinux-testsuite. We had previously looked at using
this support for /dev/kvm. Correct labeling of the inodes may require
modification to the driver depending on the approach desired.