Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47995 - [steam] 80-steam-controller-permission.rules is a potential security problem!

Attached to Project: Community Packages
Opened by Manuel Reimer (M-Reimer) - Tuesday, 02 February 2016, 18:00 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 02 February 2016, 18:34 GMT
Task Type Bug Report
Category Packages: Multilib
Status Assigned
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No

Details

The steam controller driver, built into steam, runs as regular user and as such requires usermode access to uinput. This is what 80-steam-controller-permission.rules does.

The problem with this is, that it allows any software, running as regular user, to emulate a keyboard and maybe listen to other events to find out when the current session exits or the session is switched. This way malicous keypresses and commands can be sent to other users sessions.

Currently the only way to get rid of this is to create an empty 80-steam-controller-permission.rules in /etc/udev/rules.d/

I think only a minority of the steam users use the steam controller and so I think it would be better if this feature would require some kind of "opt in" mechanism. Maybe create a new group "steamcontroller" and require the user to be added to this group to be able to use the steam controller.
This task depends upon

Comment by Jan (medhefgo) - Friday, 08 July 2016, 12:58 GMT
This should not be a security issue since the uaccess tag only gives permission to the user whose session is active.
Comment by Manuel Reimer (M-Reimer) - Friday, 08 July 2016, 14:14 GMT
It is a security problem. Once you managed to get your device registered with uinput, you keep the permissions to provide it. This means, that an running uinput driver doesn't get killed by the kernel if I, for example, open a second session with another user. This means that the first session is able to type keys into my second session. This even works if I switch away from X at all (Ctrl + Alt + Fx). So some "bad software", started from my X session, can type into my root session running on a separate virtual terminal.

I still think that it is *not* the majority of Steam users that also own the Steam controller and even if you own the Steam controller this doesn't mean that you use the Steam built-in driver. There are drivers available which run as "real" system daemon and make the Steam controller usable even without Steam at all.

The people, using the Steam controller with the Steam built-in driver, could easily add their user, they plan to use the controller with, to some group and all the other users (most probably the big majority) don't have to take this security risk.

Loading...