Re: LSM policy options for new GPIO kernel driver interface

"Weber, Matthew L Collins" [off-list ref] 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