LSM policy options for new GPIO kernel driver interface

LSM policy options for new GPIO kernel driver interface

[Weber, Matthew L Collins]

All,

Since the 5.10 kernel, the GPIO subsystem has migrated from a sysfs based GPIO export method [1] (everything is a file) to a character device[2] + library[3].  The new framework[2] provides users with signal debouncing and other features that benefit embedded products.  The legacy method[1] allowed fine policy control of who can export / set / get the GPIO state.  We have not found a similar security policy path with the new approach.  Has anyone brainstormed strategies for the new character device-based interface without adding a userspace broker to enforce another level of rules?  The ideal case would be to keep all the controls within the SELinux refpolicy such that testing can be all-inclusive.

I'd be interested in what people think, such that I can prepare a university research project submission for Fall 2021 to build a prototype. 

Best Regards,
--
Matt Weber

[1] https://www.kernel.org/doc/html/latest/driver-api/gpio/legacy.html#sysfs-interface-for-userspace-optional
[2] https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
[3] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

Re: LSM policy options for new GPIO kernel driver interface

[Dominick Grift]

"Weber, Matthew L Collins" <Matthew.Weber@collins.com> writes:

> All,
>
> Since the 5.10 kernel, the GPIO subsystem has migrated from a sysfs
> based GPIO export method [1] (everything is a file) to a character
> device[2] + library[3].  The new framework[2] provides users with
> signal debouncing and other features that benefit embedded products.
> The legacy method[1] allowed fine policy control of who can export /
> set / get the GPIO state.  We have not found a similar security policy
> path with the new approach.  Has anyone brainstormed strategies for
> the new character device-based interface without adding a userspace
> broker to enforce another level of rules?  The ideal case would be to
> keep all the controls within the SELinux refpolicy such that testing
> can be all-inclusive.
>
> I'd be interested in what people think, such that I can prepare a
> university research project submission for Fall 2021 to build a
> prototype.

Disclaimer: I am not qualified to give advice

SELinux supports IOCTL allow-listing and so access to the various GPIO
IOCTL can probably already be controlled.

So for example you can probably already control access to things like:

GPIO_GET_CHIPINFO_IOCTL
GPIO_GET_LINEINFO_UNWATCH_IOCTL
GPIO_V2_GET_LINEINFO_IOCTL
GPIO_V2_GET_LINEINFO_WATCH_IOCTL
GPIO_V2_GET_LINE_IOCTL
GPIO_V2_LINE_SET_CONFIG_IOCTL
GPIO_V2_LINE_GET_VALUES_IOCTL
GPIO_V2_LINE_SET_VALUES_IOCTL

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.

>
> Best Regards,
> --
> Matt Weber
>
> [1] https://www.kernel.org/doc/html/latest/driver-api/gpio/legacy.html#sysfs-interface-for-userspace-optional
> [2] https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
> [3] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

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

[Weber, Matthew L Collins]

Dominick,

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

Best Regards,
Matt

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