search

flathub / com.valvesoftware.Steam

https://flathub.org/apps/details/com.valvesoftware.Steam
335 stars 70 forks source link

[UX] Disable access to NetworkManager #850

Open bendlas opened 2 years ago

bendlas commented 2 years ago

Expected behavior

Steam should be able to run without elevated privileges.

Observed behavior

Workarounds

Proposed fix

References

Remarks

bendlas commented 2 years ago

It seems like this has been

I propose fixing this again, by reverting the revert, and instead advise users how to let Valve snoop on their Wifi passwords, in case a fast startup is more important to them.

cc @nanonyme @gasinvein

gasinvein commented 2 years ago

Steam doesn't gain admin perms from talking to NetworkManager.

And restricting NetworkManager access causes ValveSoftware/steam-for-linux#4979

bendlas commented 2 years ago

Steam doesn't gain admin perms from talking to NetworkManager.

Maybe. But for a regular user, it's just an admin dialog. And there must be a reason that PolicyKit requires an Admin password, no?

And restricting NetworkManager access causes ValveSoftware/steam-for-linux#4979

1) For me it doesn't. I've been running steam without NM with many games for a long time. 2) Do you think that providing a fast startup for a subset of users is more important than providing a secure default for everybody? Especially when we can just document flatpak override --system --system-talk-name=org.freedesktop.NetworkManager com.valvesoftware.Steam for said subset? We're already documenting how to enable additional library folders ... 3) Thanks for helping ping the second ticket at Valve's tracker ;-) It really is their bug to fix.

EDIT btw, if you read carefully, @gasinvein, I never said admin perms. I said elevated privileges and admin password, both of which are undubitably true. And IMO, this misunderstanding just underscores why relying on such nuances for the security architecture of a sandbox is a bad idea (tm)

gasinvein commented 2 years ago

But for a regular user, it's just an admin dialog.

Regular users usually have their distros set up NM-related policies in a way that they don't see the authorization dialogue for talking to NM. Otherwise, I'd say that something is wrong with the host setup.

And there must be a reason that PolicyKit requires an Admin password, no?

Polkit here authorizes certain DBus calls that the client makes. Unless NM somehow allows arbitrary code execution (which I believe it doesn't), none of the client processes gains elevated privileges. You're probably confusing pkexec invocations (which indeed does run proceeses as root) with DBus talks authorization.

bendlas commented 2 years ago

Look, I really don't want to get into a pissing match over this. I just think that flatpak is our best bet right now to defend against permissions overreach from proprietary software (short of a full-blown VM). I'm actually switching my steam installation to flatpak for this. I think I did a very thorough job researching this and I'd ask you to return the favor by carefully reading what I wrote with a generous mindset. And please let me (re-)clarify some of those points:

  1. Steam can talk to my NM just fine for connection status, ip addresses and such. What is blocked by PolKit is the GetSecrets call, which, if I'm not mistaken, is for getting access to Wifi passwords and such. I would very much expect PolKit to intervene on this and any mainstream distro which allows this without prompt (e.g. by adding user to the networkmanager group) is misconfigured IMO
  2. What's especially aggravating is Steam repeating that prompt many 10s of times before giving up
  3. Accessing Wifi passwords certainly is an elevated privilege, regardless of whether it happens in-process or through a socket
  4. I don't think I'm confusing pkexec, unless Steam also runs that (which it shouldn't)

And if you'll allow me a slightly tongue in cheek comment: I don't think anybody expected log4j to facilitate arbitrary code execution either. Yet, everybody now agrees that allowing that hole was a bad idea ...

gasinvein commented 2 years ago

We want decent out-of-the-box experience. Prompting everyone to do some special actions in order to fix some inherent issue isn't a good UX, and yes, in my opinion, restricting NM access isn't worth it. For comparison: we already prompt users to do overrides in order to add game library on an external drive; this also isn't a good UX, but not all users need it. And not giving the app access' to all users files certainly worth slight UX degradation for some users.

I'll be happy to remove the NM permission when Steam switches to a more secure way to get connection status, e.g. the NetworkMonitor portal. But until then, we'd just degrade the ootb UX for a questionable security gain.

Accessing Wifi passwords certainly is an elevated privilege

Elevated privileges in Linux usually mean either EUID 0 or some additional capabilities. Neither of these are (nor can be, presumably) gained by the Steam Client from just talking to NM. If you've mean something different by "elevated privilege" - please elaborate.

nanonyme commented 2 years ago

Well, having admin prompt thrown at you repeatedly is definitely also bad out-of-the-box experience. Has this usage of GetSecrets been reported to Valve as a bug?

bendlas commented 2 years ago

https://github.com/ValveSoftware/steam-for-linux/issues/7856#issuecomment-864527155

gasinvein commented 2 years ago

Well, having admin prompt thrown at you repeatedly is definitely also bad out-of-the-box experience.

It doesn't affect most users. E.g. here on Fedora 35 with full-default policies polkit doesn't prompt me for password when calling NM GetSecrets methods.

Has this usage of GetSecrets been reported to Valve as a bug?

Yes, and IMO this is certainly a bug to be fixed on the Steam Client side.

bendlas commented 2 years ago

If you've mean something different by "elevated privilege" - please elaborate.

I'm tallking of "elevated privilege" in the sense of horizontal privilege escalation on a systems level. Not the narrow definition of vertical escalation, that is about changing the level of the process you're running in.

And as I said before, due to an unbounded amount of games code, downloaded and run by steam, this could easily have some characteristics of vertical escalation as well.

gasinvein commented 2 years ago

Do you think that providing a fast startup for a subset of users is more important than providing a secure default for everybody? Especially when we can just document flatpak override --system --system-talk-name=org.freedesktop.NetworkManager com.valvesoftware.Steam for said subset?

Yes, in this case I think it is. Non-savvy users won't read wikis and apply overrides. They'll just assume this is a flatpak-induced issue (and be right about that) and just install the distro package instead, without any sandbox and without the startup delay issue. No security is gained for them.

nanonyme commented 2 years ago

@gasinvein the fact that it doesn't prompt for password on Fedora is worse, not better. It means Steam reads WiFi passwords there without any user consent.

gasinvein commented 2 years ago

the fact that it doesn't prompt for password on Fedora is worse, not better.

Maybe I'm putting too much trust into Fedora devs, but I believe they know what they're doing. Even if not, it's up to them to fix it, if they consider this a bug.

bendlas commented 2 years ago

I'd like to offer, that I have been successfully gaming dozens of titles on Steam for years on systemd-networkd with wpa_supplicant or iwd, including multiplayer games with P2P connections and off and on proton. i.e. w/o NM in many different constellations

No issues with startup times, no issues with any of my titles.

And also, surely, we're not guaranteeing a working UX only just if installed on fedora, either, because we're not trying to be rpm or yum and also there already is rpm and yum, right?

teohhanhui commented 2 years ago

It doesn't affect most users.

"Works on my distro"? This affects openSUSE users out of the box. That's enough reason to fix it.

gasinvein commented 2 years ago

This affects openSUSE users out of the box.

Because openSUSE is the only distro which doesn't by default add the user created at install time to wheel or sudo group.

That's enough reason to fix it.

Removing NM access is not a fix, it's a workaround at best, and it comes at non-negligible cost. A proper fix would be Steam stopping using NM, at least in the way it does.

bendlas commented 2 years ago

Because openSUSE is the only distro

No it isn't! Please stop using hyperbole and cherry-picking your arguments. It confuses everybody and makes you seem like a threat actor.

Removing NM access is not a fix, it's a workaround at best, and it comes at non-negligible cost

Breaking everybody not on Fedora, or forcing them to give wheel to their steam users is also a non-negligible cost.

gasinvein commented 2 years ago

@bendlas If you want to keep the discussion technical, please avoid personal attacks. If you want to make it personal, I'd rather stop participating in it.

bendlas commented 2 years ago

@bendlas If you want to keep the discussion technical, please avoid personal attacks. If you want to make it personal, I'd rather stop participating in it.

@gasinvein At this point, actually, I'd rather you do.

Let me explain: I have wasted hours of my life in chat, trying to get a feel for what your position was and what would be "over the line" for you. Despite my best efforts, I couldn't. Instead you're still derailing, responding to everybody who agrees with this, with incoherent arguments. So even just from a "technical discussion" standpoint, many things you're saying just don't make sense.

On top of this: This is not a technical issue, so we can't expect to keep the discussion purely technical. UX is not technical. Security is not purely technical. Flathub is not just targetting Fedora. I'm done being courteous.