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/