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/
