Hacker News Reader

Ah, that's fair.

Still, assuming a lack of other sandboxing, running a keylogger is pretty trivial. It's not by default, as you put it, but an un-sandboxed application has enough access to your filesystem to perform tomfoolery and get your credentials. At that point, there's no need to start a terminal, you just load some shellcode in whatever process you control, and say goodbye to your data.

As for sandboxing, well, you're right, although one could sandbox X11 if they wanted to. "X-on-X" is actually a thing, rarely used outside developing X, but I could see it being used for seamless sandboxing with some work. Work that, inevitably, no-one will actually do, so there's that ;)

It actually is feasible to sandbox X11 in that way, I believe this is what security-focused distributions like Qubes and Whonix do. But yeah, it is essentially working around the problems with X11 and not really suitable for ordinary use.

To me the real progress needed is that applications need to move to using sandbox-friendly APIs so they don't break when put in the sandbox, and moving to Wayland is a key part of that. Applications built around the X11 idea of always having full access to everything will need changes regardless of what sandboxing solution is in use.

> I’m saying that because if you ever type in your password, e.g. into a screenlocker, into a terminal with sudo, or an apt-get gui, every application can listen to those input events.

And any program can (on a relatively default box) trace arbitrary programs under your gid and scan memory for passwords. The real issue here is that there are very weak process boundaries within a gid (because it is historically most convenient), not necessarily a lot wrong with X11.

Every other boundary can be restricted relatively easily. For example, flatpak already solves the issue you mention.

But the X11 boundary can’t be resolved unless you put a whole X server into every single application’s container with XonX, or you replace X11.

Which is part of why wayland exists.

Can be restricted when appropriate. Removing the ability to share resources and calling Wayland complete is what people are laughing at.

Putting holes into a solid block is a lot easier than patching something that looks like swiss cheese.

(Sorry for butchering up the quote)

Wayland’s security is not sufficient but necessary for a safe OS. (As others mentioned X-on-X can also be a sufficient solution for that)

> With X11, even a flatpak without any special permissions or bind mounts can still basically control your system. Just listen for input events until you see the keys "s u d o", then listen until you see something that looks like a password, then wait until the user is not paying attention, and inject virtual input events to start a terminal and inject input events to run "sudo rm -rf /*" with the password you captured earlier.

Why such complication? An hostile application can simply add an "evil" line to your .bashrc and you are fucked anyway. No need to keylog anything, nor the fancy stuff that you describe. It doesn't need to be a graphical application, even. The "ls" command can do it!

Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.

That’s the point of flatpak. But as long as you use X11, there’s one single privilege escalation path left, and that’s the complicated one I described above.

> Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.

That's just false. Flatpak has the ability to restrict access to such resources, but it's completely up to the author of a Flatpak application if they make use of it. Like my file manager and text editor are Flatpaks fetched from flathub.org and both applications have unrestricted access to my whole home directory by default, including my shell configuration -- even the Chromium Flatpak can do that by default.

Edit: I just counted, out of 30 installed Flatpaks from flathub.org 19 have full access to either my whole home directory or the host file system.

That's true, but not really relevant. The point of flatpak is that it can sandbox applications if just the right flag is set, but this sandboxing becomes useless on X11.

Long-term, all applications should strive to be properly sandboxed this way

> That's true, but not really relevant.

Of course it is. Someone who read your comment and didn't question it might now believe that Flatpaks would enforce filesystem sandboxing and prevent, say some game, from accessing their shell configuration or ssh keys. That's false and it's dangerous, because nothing is worse from a security perspective than misinformed users who have a false sense of security.

> but this sandboxing becomes useless on X11.

That's also false. For example X11 provides mechanisms like the X11 security extensions which prevent clients from accessing each others data through the X11 protocol (like key events or buffer content), which means when I run my color picker or xev in a such an X11 security context they literally stop working outside of their own window. Firejail makes this type of sandboxing easily accessible and it also provides the ability to easily isolate x11 clients with xpra or xephyr.

So it's not like it can't be done, it's just that Flatpak doesn't care about it -- which is fine. With dbus you get the same issues, because clients on the same bus aren't isolated from each other. In this instance however Flatpak cared and implemented a dbus proxy to isolate clients from each other without throwing dbus away.

> all applications should strive to be properly sandboxed this way

I agree, but definitely not this way! The sandboxing details must be 100% controlled by the user. The people who distribute the application should have no say whatsoever about their required permissions. That's ultimately for the user to decide. From the point of view of the application, all files are visible, but it may be a mock filesystem with mock resources. Letting the application distributors chose the permissions defeats the whole purpose of the sandboxing.

What if I don't trust the person that sent me the flatpack container itself? A truly secure sandboxing should be a standard OS facility, not tied to a package distribution method. The flatpack/snap model is all wrong. I need to run arbitrary hostile applications in a safe manner, not only those that the developers have decided to distribute in a certain form.

Sure, but the flatpak model is a way to get these advantages for as large a userbase as fast as possible. If you use flatpaks without bind-home under wayland today, you’ve significantly improved your actual security already.

Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.