fprintd SPI support

[benzea]

fprintd/libfprint 1.92.0 adds support for SPI devices. These are accessed through /dev/spidev* (there is a udev rule to bind the spidev driver).

I am not sure as I cannot test this. But I suspect that the selinux policy needs to be adjusted to grant access to the device.

[benzea]

Oh, I forgot (and actually forgot about that upstream in the systemd config too!). hidraw device access may also be necessary in order to do a HW reset of the fingerprint reader.

i.e. opening an hidraw device and doing a HIDIOCSFEATURE ioctl.

[zpytela]

@benzea Can you give some usage example? The type for the device file is usb_device_t and a few dozens of SELinux domains have already access to it.

# sesearch -A -t usb_device_t -c chr_file -p read
allow apcupsd_t usb_device_t:chr_file { append getattr ioctl lock open read write };
allow arpwatch_t usb_device_t:chr_file { append getattr ioctl lock open read write };
allow asterisk_t usb_device_t:chr_file { append getattr ioctl lock open read write };
allow bluetooth_t usb_device_t:chr_file { append getattr ioctl lock open read write };
allow brltty_t usb_device_t:chr_file { append getattr ioctl lock open read write };
allow colord_t usb_device_t:chr_file { append getattr ioctl lock open read write };

[benzea]

Hm, I don't quite understand.

The spidev and hidraw devices have different a major number compared to USB. So I really doubt that those are covered by the usb_device_t rule.

$ cat /proc/devices | grep -E hidraw\|spi\|Chara\|Block
Character devices:
153 spi
240 hidraw
Block devices:

Right, I see the following now:

policy/modules/kernel/devices.fc:/dev/hidraw.*          -c      gen_context(system_u:object_r:usb_device_t,s0)
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw0")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw1")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw2")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw3")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw4")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw5")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw6")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw7")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw8")
policy/modules/kernel/devices.if:       filetrans_pattern($1, device_t, usb_device_t, chr_file, "hidraw9")

If that means that both hidraw[0-9] and spidev are always tagged as usb_device_t then this will work just fine already. I am a bit surprised to see that, but fine with me.

[benzea]

So, I suspect this is "not a bug".

[zpytela]

@benzea, if usb_device_t is an appropriate type for /dev/spidev.* and the domain which access the device already have the permission, there should be no problem. If you think the type should be different, please explain and we can possibly change it.

[benzea]

Nah, don't worry really. I just really didn't expect that usb_device_t is used for other device types.