| Summary: | /dev/input/event* not accessible by users by default | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gregor Mückl <GregorMueckl> |
| Component: | [OLD] Core system | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | base-system, udev-bugs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=514174 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Gregor Mückl
2008-11-15 12:21:38 UTC
I thought /dev/js* is for accessing joysticks from userspace. /dev/js* is the classical name, but that doesnt cover the myriad of input devices out there (touchscreen much?). so /dev/input/event* seems to be the framework everything is coalescing on. (In reply to comment #2) > /dev/js* is the classical name, but that doesnt cover the myriad of input > devices out there (touchscreen much?). so /dev/input/event* seems to be the > framework everything is coalescing on. > Right, but that provides a different API/ABI then the /dev/js* devices. Most apps which use joysticks use /dev/js*. Allowing these devices to be easily readable by non-privileged users provides a serious security concern (read: key loggers by regular users). That security concern is mostly related to devices which would be accessed through the X server anyway (keyboard, mouse and maybe tablets). I do not see any security risks in making joysticks (and other such gaming devices) world-accessible. My knowledge of the capabilities of udev is quite limited, but would it not be possible to set the access rights to event files depending on the type of device that they represent? no one was proposing we make all event devices directly accessible to the user. i was pointing out that using some event devices directly is not a bug. So for this to get any further someone has to provide code, I only have mouse/keyboard and lirc (not yet using input layer). Is this bug still accurate with current stable udev 197-r3? I guess so, but please verify. I can confirm that permissions are still too strict with current udev-197-r4. They are rwxr----- root:root. But /dev/input/js0 is rwxr--r-- with the same ownership, which is fine. (In reply to comment #8) > I can confirm that permissions are still too strict with current > udev-197-r4. They are rwxr----- root:root. But /dev/input/js0 is rwxr--r-- > with the same ownership, which is fine. Would it be somewhat crazy to have group & other have read permissions for eg. keyboard and mouse, allowing things like keyloggers? 700 sounds right, seems like the software assuming 744 has the bug here or have dev-games/ois install as suid root to have such access if you think it's safe You are not aware of the real issue here: For keyboard and pointer devices I would agree. These should belong either to root or the user owning the current terminal. But there is a host of other devices that need to be user-accessible. Joysticks and game controllers are good examples for that. Input of sensitive data is not usually performed with these devices and the only way to use them is through device files like /dev/input/event* or - sometimes, but not always - /dev/input/js*. OIS and Steam are two legitimate examples for software that wants to access /dev/input/event*. In the case of Steam, the inability to access these devices breaks Big Picture, the controller-friendly Steam UI, in a significant way. In the case of OIS, this breaks any game using it for joystick input. Make /dev/input/event* user-readable for any type of device that could be considered a gaming device. This requires some sort classification of the devices in the hardware database. Alternatively, change ownership to root:games and set the device files to 740. In either case, assuming 700 indiscriminately for all /dev/input/event* files is broken. Re: Comment 10: I do not see how setting a shared library suid would help. (In reply to comment #11) no input device should be world readable -- end of story you might be able to argue game group ownership of just joysticks, but even that is a bit of a hard sell i thought hal & friends used to handle this via like plugdev, but i don't know what the new hotness is there I never spoke of input devices becoming world-readable in Comment 11. I chose the word user-accessible specifically to allow that only a single current user gets this kind of access. This would be a valid solution. Does this mean that ConsoleKit needs to be involved in this? Or is there another mechanism to track the currently active session? Create group "input" and then: These to /lib/udev/rules.d/40-gentoo.rules: SUBSYSTEM=="input", KERNEL=="mouse*|mice|event*", MODE="0640", GROUP="input" SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0640", GROUP="input" To override these from /lib/udev/rules.d/50-udev-default.rules: SUBSYSTEM=="input", KERNEL=="mouse*|mice|event*", MODE="0640" SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0644" Then it should look like, for example: crw-r----- 1 root input 13, 63 Jan 28 00:53 /dev/input/mice crw-r----- 1 root input 13, 32 Jan 28 00:53 /dev/input/mouse0 crw-r----- 1 root input 13, 32 Jan 28 00:53 /dev/input/event0 Then admin can add the user to input group, or add input group to games group, depending on how much he trusts the users Does that make any sense? (In reply to comment #13) > i thought hal & friends used to handle this via like plugdev, but i don't > know what the new hotness is there I can't think of any freedesktop package that would currently handle this; udisks is for disks and upower for power management, nothing generic for joysticks AFAIK "plugdev" group was also invention of HAL and is not something you can rely on, packages still needing it need to create the group themselfs... (In reply to comment #16) isn't this the whole point of consolekit ? when you log into the "console" of the system, you should get automatic ownership of the "local" input devices. (In reply to comment #17) > (In reply to comment #16) > > isn't this the whole point of consolekit ? when you log into the "console" > of the system, you should get automatic ownership of the "local" input > devices. right, sorry, sys-auth/consolekit[acl] would install udev-acl helper and /lib/udev/rules.d/70-udev-acl.rules and it already has this line: SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl" which would set it ACL like crw-rw----+ but that only works for input devices that udev recognizes are joysticks and this bug seems to be about the ones that are joysticks but are not identified as such there is no rule in 70-udev-acl.rules that would do something for generic input devices (In reply to comment #18) any reason for keeping the joystick limitation ? afaik, consolekit is limited to one console, so giving the user at said console write access to all event devices doesn't sound unreasonable. Upstream commit, commit went in post-214, so it's currently only available in =sys-fs/udev-9999: http://cgit.freedesktop.org/systemd/systemd/commit/rules/50-udev-default.rules?id=3dff3e00e044e2d53c76fa842b9a4759d4a50e69 I believe we can close this bug finally. 21 Jun 2014; Samuli Suominen <ssuominen@gentoo.org> udev-9999.ebuild: Create group "input" wrt bugs #246847 and #514174 It will be available to ~arch with next release, udev-215 (or if I'm doing other fixes that need revision bumped 214, I'll include the patch too) Bug 514174 will follow it's inclusion to baselayout And I'm not comfortable adding ACLs for all input devices from ConsoleKit rules, it should be specific to what it recognizes as joysticks, otherwise it's security hazard (ie. local user can escalate privileges) |
