I'm not entirely sure what Alex meant there, but I think his comment there was that the only way to be able to make use of this (at least until user namespace support lands in Docker) is for the user to have effective root on the system. So even if the sandboxing works, it's being done at a cost of requiring that, outside the sandbox, the users have an easy and passwordless way to gain root. This not only gives apps way more power than they had in the event of a sandbox escape mechanism (like the X11 socket), it also gives every unsandboxed app on the system way more power.

It's kind of like the general distaste for setuid binaries. If you have a correctly-written setuid binary, then you can use it to sandbox a process by, say, running it in a chroot. But if it's not correctly written, you have problems on your hands that far outweigh the problem you were originally trying to solve. So a random desktop app that ships with a setuid helper binary is going to be seen with suspicion. (Chrome is the only one I can think of that ships one, but they probably employ the people most qualified to write a bug-free setuid app, and they're getting rid of it in favor of user namespaces anyway.)

Of course, for the average developer desktop, processes probably have fifteen ways to gain passwordless root anyway. I certainly set sudo to nopasswd for convenience. :) So on a developer desktop, it's a nifty hack, although it doesn't gain you security against a malicious app/exploit. But as a general-purpose sandboxing approach, it's a bad tradeoff to make.

Its super easy to get out of this container. Just connect to the x socket, then look for a terminal window, the start injecting keyboard input into it.

If you break the app you have +- the same access.. see if you break irssi you're not root either.

This stuff is only sort-of reliable when-containers-dont-have-root-bug-today if you run that as a separate user than yourself in a different X server

So basically not cool.

The way GNOME is doing ACTUAL sandboxing is much neater. Turns out it doesn't use Docker also. Go figure /sarcasm.

Gnome sandboxing uses exactly the same technologies behind the scenes as Docker uses: cgroups, namespaces, ... They add the additional requirement that they need Wayland to circumvent the security issues that X11 presents them. Other than that, you could do it just the same way.

So your "when-containers-dont-have-root-bug-today" applies to Gnome too...

Also: there is no such thing as 'actual' sandboxing. There are many forms of sandboxing, containers (not docker-exclusive, as Gnome is using it exactly the same way) is one form, but we also know Virtual Machines, the Java VM, Javascript in a browser, ... the list goes on - all meaning the same thing: shield an application from everything else on the computer and try to prevent it from breaking out.