"Weber, Matthew L Collins" <Matthew.Weber@xxxxxxxxxxx> 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@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift