LSM policy options for new GPIO kernel driver interface
dominick.grift at defensec.nl
Tue Aug 3 17:22:56 UTC 2021
"Weber, Matthew L Collins" <Matthew.Weber at collins.com> writes:
> Since the 5.10 kernel, the GPIO subsystem has migrated from a sysfs
> based GPIO export method  (everything is a file) to a character
> device + library. The new framework provides users with
> signal debouncing and other features that benefit embedded products.
> The legacy method 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
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:
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
>  https://www.kernel.org/doc/html/latest/driver-api/gpio/legacy.html#sysfs-interface-for-userspace-optional
>  https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
>  https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/
gpg --locate-keys dominick.grift at defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
More information about the Linux-security-module-archive