On Mon, 03 Feb 2025 at 08:45:25 +0100, Fabian Greffrath wrote:
> But, to be honest, if you already share your computer hardware and access at
> the system console with a malicious user, there may be way more obvious ways
> to get attacked than through the steam-devices package, right?
Well, yes. The most obvious one is that with physical access to the
computer, they can insert a hardware keylogger, or reboot into live
media, or any other "physical presence required" attack.
The part of this that concerns me most is /dev/uinput, which you likely
don't actually need if you aren't running Steam (but it's a requirement
for increasingly many Steam features, so steam-devices definitely does
need to provide access to it).
I think concerns about reprogramming a game controller with malicious
firmware are particularly overblown, because if the attacker has
physical access to it, they can ... already do that, by plugging it into
a different computer! (Game controllers being a notably portable category
of device.) But it's something that was treated as a showstopper by some
of the systemd team when, with my $day_job hat on, I tried to upstream
a subset of this into udev.
What I want to avoid is adding a Recommends (or possibly Suggests) to
SDL as you suggested, and then finding that a year or two later I'm being
required to spend large amounts of high-priority time on dealing with
someone reporting this as a security vulnerability, and demanding my
immediate attention and/or resignation.
smcv
