Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package

[Simon McVittie]

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