Red Hat Bugzilla – Bug 300811
pam_console needs permission to set the owner of /dev/input/uinput for fingerprint readers to work
Last modified: 2008-01-30 14:05:51 EST
Description of problem: pam_console needs to set the ownership of /dev/input/uinput to the currently logged-in user on the console for fingerprint readers (as supported by the thinkfinger package) to be able to operate correctly from a user session (so the fingerprint reader can be used to unlock a locked screen, for example). This requirement will go away when ACL support is moved from hal to udev, but until then this is the only way to have a working fingerprint reader. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.6.4-42.fc7 How reproducible: always Steps to Reproduce: 1. install thinkfinger on a machine with a fingerprint reader 2. reboot 3. log in to X Actual results: - see this AVC in the logs: type=AVC msg=audit(1190154617.728:17): avc: denied { getattr } for pid=2739 comm="pam_console_app" name="uinput" dev=tmpfs ino=6754 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file - /dev/input/uinput still owned Expected results: - no AVC - /dev/input/uinput owned by the logged-in user Additional info:
Created attachment 202611 [details] Here's a selinux policy module that fixed the problem for me. Though if you added a new file context for /dev/input/uinput, that would probably be better.
A better way to do this would be to set the file context semanage fcontext -a -t scanner_device_t /dev/input/uinput Fixed in selinux-policy-2.6.4-43.fc7.src.rpm
Note that /dev/input/uinput isn't really a scanner, and it's not specific to fingerprint readers. It's created by the uinput.ko kernel module, and is an interface to allow userspace to interact with the kernel input layer. It's used to synthesize keyboard and mouse input programatically. So there may be a better content to use than scanner_device_t. That being said, whatever works. :)
These are how we currently have /dev/input defined. /dev/input/.*mouse.* -c gen_context(system_u:object_r:mouse_device_t,s0) /dev/input/event.* -c gen_context(system_u:object_r:event_device_t,s0) /dev/input/mice -c gen_context(system_u:object_r:mouse_device_t,s0) /dev/input/js.* -c gen_context(system_u:object_r:mouse_device_t,s0) /dev/input/uimput -c gen_context(system_u:object_r:scanner_device_t,s0) So we can create another device or if you know of an existing device that it matches, we can change it to this.
mouse_device_t?
Of the existing types, I'd say event_device_t is probably the best fit, because it can be used to generate keyboard, mouse, tablet, etc. events. Also, looks like there's a typo in the path, it's /dev/input/uinput
Hmm, it is not fixed in the release mentioned. Judging from the changelogs, looks like the fix made its way to the rawhide selinux only.
Fixed in selinux-policy-2.6.4-44.fc7.src.rpm
That fixes the problem, thanks. Would it be possible to push this update along with thinkfinger? If not, I'll just wait.
Bulk closing a old selinux policy bugs that were in the modified state. If the bug is still not fixed. Please reopen.