-
-
Notifications
You must be signed in to change notification settings - Fork 389
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
Comments
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. |
Can you explain the problem and solution more please? There are two relevant permissions:
It's clear that you only care about the case where the flatpak is using So in this case, how exactly can XWayland be abused to escape the sandbox and read the host |
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
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 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.
What I would suggest for this use-case (and in fact what I use myself for this use-case) is:
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. |
From what I understood, those who still use Xorg or use apps with 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. |
Checklist
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.
The text was updated successfully, but these errors were encountered: