Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request]: Sandbox proton/X11 games using xpra for secure linux gaming #5744

Open
2 tasks done
ParetoOptimalDev opened this issue Mar 24, 2024 · 4 comments
Open
2 tasks done

Comments

@ParetoOptimalDev
Copy link

ParetoOptimalDev commented Mar 24, 2024

Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Prior issues

Previously there were X11 requests in #3833 and #3864.

Context

Recently I switched to using flatpak for steam after Massive ‘Apex Legends’ Hack Disrupts NA Finals, Raises Serious Security Concerns in potential the case of a client RCE being the way that the hack was done.

The steam flatpak image uses it's own directory, so I at least felt safe in that access to other directories such as ~/.ssh would be disallowed.

However I quickly found that X11 socket access can be a way to escape the sandbox.

Suggestion

Given that XWayland is here to stay for gaming via Proton, I'd argue it should be higher priority to have X11 sandboxed to have better security for cases like mine I mentioned above.

I propose implementing something with Xpra as described here.

@vgdaut
Copy link
Contributor

vgdaut commented Mar 26, 2024

I agree that this feature should be implemented. Flatpak should be as secure as reasonably practicable, so this feature should the the default way to launch x11 apps.

@mcatanzaro
Copy link
Collaborator

However I quickly found that X11 socket access can be a way to escape the sandbox.

Can you explain the problem and solution more please?

There are two relevant permissions:

  • --socket=x11 permission, which mounts the host system's X11 socket. Insecure.
  • --socket=fallback-x11 permission, which mounts the host system's X11 socket if not running under Wayland. Insecure if not running under Wayland.

It's clear that you only care about the case where the flatpak is using --socket=fallback-x11 and is running under Wayland; otherwise, Xpra surely doesn't provide any security benefit, because the application can talk directly to the host X11 socket.

So in this case, how exactly can XWayland be abused to escape the sandbox and read the host ~/.ssh? I thought this is currently assumed to be secure and not possible?

@smcv
Copy link
Collaborator

smcv commented Mar 26, 2024

how exactly can XWayland be abused

My understanding is that it can take screenshots of other X11 windows, and inject input into other X11 windows. For instance if you're running an xterm in parallel with a malicious or compromised Flatpak app with X11 enabled, then the Flatpak app can run arbitrary commands by "typing" into it.

otherwise, Xpra surely doesn't provide any security benefit, because the application can talk directly to the host X11 socket

I believe the idea is that Xpra would be used in much the same way that Flatpak uses xdg-dbus-proxy for D-Bus: Xpra runs on the host, Xpra's client side talks to the real X server (whether that's Xwayland or Xorg), and the sandboxed Flatpak app is given the necessary XAUTHORITY credentials to access Xpra's server side, but not the real Xwayland or Xorg socket.

It seems like a good idea in principle, but given the limited bandwidth of the Flatpak maintainers (who are all responsible for too many other things that aren't Flatpak, as far as I know), it seems unlikely to happen unless someone who wants this feature can step up to do the implementation.

for secure Linux gaming

What I would suggest for this use-case (and in fact what I use myself for this use-case) is:

  • Create a new user account, perhaps named gamer or something. Don't give it administrative privileges (sudo and so on).
  • When you want to play games, either log out, or use fast user switching (e.g. GNOME's "Switch User") to switch to the gamer account.
  • Optionally, use Flatpak or similar sandboxing as well, as a second layer of defence.
  • When you've finished playing games, log out from the gamer account and back into your normal account.

That way, you have ~ 40 years of Unix multi-user support protecting your personal files from your games, and you aren't relying on either Flatpak or Xpra as the only security boundary.

That's less convenient than running Steam and games sandboxed in your normal account's session, but since games are often running full-screen as the only thing that is visible, receiving input and playing audio, and the level of integration expected between games and everything else is relatively low (for example they're unlikely to need to interact with most portals), it's less of a burden than it would be for a typical application like a web browser or an editor.

Something like Steam is particularly difficult to sandbox, because sandboxing mechanisms like Flatpak are based around the idea that an app has a particular set of requirements, but Steam is more like an app-framework itself than being like an app - so it needs the union of every Flatpak permission that you want any Steam game to be able to access. None of this is really Flatpak-specific, the same would be equally true for competing app frameworks.

@vgdaut
Copy link
Contributor

vgdaut commented Mar 27, 2024

So in this case, how exactly can XWayland be abused to escape the sandbox and read the host ~/.ssh? I thought this is currently assumed to be secure and not possible?

From what I understood, those who still use Xorg or use apps with x11 permission can benefit from X11 sandboxing.

I tried to launch a flatpak app with Xpra. Unfortunately, it takes time to launch, so it's not acceptable to enable Xpra by default, especially considering that it likely only benefits those on legacy Xorg. Maybe Xpra could be enabled by default for Xorg users by default.

Another issue is that Xpra breaks fonts. Apps inside Xpra have small fonts. I think it similarly breaks themes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants