We need more detail than that. Looking at the steam-device udev rules, I don't see that. Nor do I see it for most of the openrgb ones. Unless you're saying the hidraw access is the problem?

That was always going to be required since SDL directly connects to controllers and manipulates them.

These rules have to be installed on the host basically no matter what.

Flat out, reverting steam-devices is probably not going to be acceptable. Some of the OpenRGB rules look a bit funky, so that might be worth discussing.

"it's uaccess on uinput. this always was a security problem and why it's not turned on."

I strongly advise against reverting the installation of Steam-Devices and OpenRGB-Udev-Rules without a more detailed assessment of the actual security risks versus the functional necessity of these rules. Here’s why:

Essential for Compatibility & Functionality
The Steam-Devices udev rules are critical for enabling proper controller support on Linux. SDL relies on these rules to interface with controllers directly, which is necessary for a seamless gaming experience. Removing them would break expected functionality for users.

No Clear Evidence of a Security Risk
As @ngompa pointed out, there has been no concrete demonstration that these udev rules introduce an actual, exploitable security issue. If the concern is about uaccess on uinput, this has always been a requirement for proper controller functionality. Without solid proof of a real-world vulnerability, a knee-jerk removal could do more harm than good.

uaccess & Security Context
While uaccess on uinput has been debated in security circles, it’s important to recognize that this is an opt-in feature, and distributions that prioritize security can restrict it further if necessary. If there is a specific, proven security exploit, then a targeted fix or additional mitigations should be discussed, rather than a full rollback.

Potential Regressions & User Impact
Reverting these rules could lead to significant regressions in user experience, particularly for Steam users who rely on proper device input handling. Breaking widespread functionality for a vaguely stated security concern—without a concrete attack vector—feels premature.

Alternative Solutions Instead of Reversion
If there is a legitimate security risk, the better approach is tightening access controls or adjusting permissions, rather than outright removal. A more granular fix, such as refining specific OpenRGB rules or adjusting hidraw permissions where necessary, would be preferable over a broad rollback.

Before considering a revert, I’d recommend a proper security audit to determine whether the risk is theoretical or practical, and if mitigations can be implemented without breaking necessary functionality.

Removing these rules could have major consequences for end users—let’s ensure that any change is backed by clear evidence, not just a general concern.

If the concern is about uaccess on uinput, this has always been a requirement for proper controller functionality.

Nobody cares about what you do on your system if gaming is important to you.

That doesn't mean we should ship insecure setups by default.

Can somebody please explain (a) what is "uaccess on uinput," and (b) what specifically is the security concern here? Thanks.

Removing these rules could have major consequences for end users—let’s ensure that any change is backed by clear evidence, not just a general concern.

But these rules were just added earlier today, so at this point I suggest we revert just to restore the previous status quo until we've had more time to debate this. It's a lot easier to add a new package than it is to automatically remove one from users' systems that we regret having added. CC @siosm

Came across this just now, so let's answer at least @catanzaro's questions: Quick check of the steam-devices package includes this line in 60-steam-input.rules:

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

Can't seem to find any linkable documentation for uaccess but it means that logind will grant access to the device to the currently active user (as seen by logind). Previously /dev/uinput was only accessible to the root user.

The implication of this is that if this package is installed, any logged in user can create a new evdev kernel device via /dev/uinput. This device will be treated as if it was plugged in hardware by virtually all of the userspace stack. There are no revocation facilities for this, so the device created stays around until the process closes the uinput fd.

As to what you can do with uinput? Pretty much anything, the libinput test suite for example uses uinput to emulate devices to make sure things work as expected, we have libinput record and libinput replay that allow us to capture any input device and replay it locally as if it was plugged in. That's (iirc) what steam does (legitimately) - it parses the HID protocol from the steam devices and converts it into a uinput device that will then look like a normal device.

A few things that I can think of beyond the "create any type of device that can send any input event at any time":
- creating enough uinput device means you run out of minors for the evdev node so plugging in a physical device won't do anything (haven't tested this though).
- the way compound devices work means if I have a uinput device that holds a button or key down, that button/key effectively becomes unusuable - compositors usually trigger a press on first down and release on last up. It's 20 LOC for any user to DoS a button.
- I had a small tool once that created random uinput devices with the intention of making sure libinput can handle odd devices. I ended up crashing the kernel so often that I had to drop the idea. Creating and destroying dozens uinput devices really fast is probably still a good way to crash things though admittedly I haven't tested this in ages. edit: found it: fuzzydevice

uinput is intended functionality when you have steam devices that you want working. Having /dev/uinput available to any user ever logged in on a system is a bit hairy.

The quick check I did didn't show OpenRGB to do the same thing, those seem to have the hidraw access rules only. These are behind vid/pid checks and appear to be limited to OpenRGB so the only drawback here is that any user could send harmful commands to your keyboard - but that's IMO a reasonable trade-off to make them work.

Then raise it with steam-devices and let's see if they can be tightened.

Then raise it with steam-devices and let's see if they can be tightened.

uhm. How do you expect this to work? it's a single kernel device that you give access to or not and that's the single requirement to functionality here. The only tightening I can think of is adding the equivalent to the recently added HIDIOCREVOKE support[1] to uinput which is unlikely to be accepted into the upstream kernel but I'm open to ideas.

[1]: coincidentally, uaccess on hidraw nodes is no longer required if the applications go through logind but not sure the full stack is ready yet.

Simple example of shutting down a machine via uinput: https://gist.github.com/whot/328dbcfa5e397d53aa6fd44c147cbf3c

Exact behaviour changes with the "Power button behavior" toggle in GNOME settings or the equivalent in the other compositors.

Then raise it with steam-devices and let's see if they can be tightened.

uhm. How do you expect this to work? it's a single kernel device that you give access to or not and that's the single requirement to functionality here. The only tightening I can think of is adding the equivalent to the recently added HIDIOCREVOKE support[1] to uinput which is unlikely to be accepted into the upstream kernel but I'm open to ideas.

[1]: coincidentally, uaccess on hidraw nodes is no longer required if the applications go through logind but not sure the full stack is ready yet.

The steam-devices udev rules exist to make it so Steam and SDL can interface with game controllers. There's also the VR headset stuff for SteamVR. Most of the rules seem to be just about that, so maybe ask if the "Steam Controller udev write access" rule is still needed?

Someone more familiar with the current state of steam devices can answer this better but my understanding is that steam talks directly to the devices via hidraw and creates uinput devices on-demand so the devices can work as regular input devices in the session. Steam effectively takes the role of a kernel input driver in userspace here.

OK, I had vague recollections of the security impact of those rules (and why they did not simply get accepted upstream) and that makes sense now. Let's revert this for now.

https://pagure.io/fedora-comps/pull-request/1102

Thank you!

I think we can close this one now. We can track it in https://pagure.io/fedora-workstation/issue/467 or maybe rather in https://gitlab.com/fedora/ostree/sig/-/issues/71 as this is mainly Silverblue specific.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/473

Please continue any further discussion there.