And a separate user account, otherwise they can just connect to the original X server. (And on almost all existent Linux systems, either running as a separate user isn't trivial or the sandboxing process has root.)

Is a separate user account necessary if the Xauthority cookie is shadowed in the sandbox? I think firejail's nested X server setup works this way, without a separate user account.

What prevents you from reading the Xauthority cookie out of disk / an existing process's environment / out of an existing process's memory / etc.? You need a sandbox to prevent it fro doing these things, which is certainly doable, but much harder than just opening a new X server.

(On a system without Yama enabled, you can also ptrace any other process running as the same user and run code as it, e.g., using gdb, but lots of desktop-focused Linux distros enable Yama to close this particular approach.)

> What prevents you from reading the Xauthority cookie out of disk / an existing process's environment / out of an existing process's memory / etc.?

The sandbox does.

> You need a sandbox to prevent it fro doing these things, which is certainly doable, but much harder than just opening a new X server.

Of course. I never said simply running a new X server is sufficient. All I asked is if the sandbox needed to run the program in a separate user account.

How many apps do this?

If you trust an application so far as to properly limit itself in what it can do by requesting a sandboxed environment so you don't have to type a few additional letters you might just as well run it without a sandbox.

Hey kind stranger who is supposed to do the garden while I go shopping, I really don't trust you. So to be sure you only do the garden and nothing else, here are the keys to my house, please ensure that every door and window is locked. Thanks.

The only other entity who could set it up for you, so every application automatically launches in a sandboxed environment, is the distributor, but then again it's your responsibility to chose a distribution that does that.

If you want security you have to do something about it at one point or another.

I think this is the wrong attitude. No one is better suited to implement a sandbox than the developer of the application. The fact that most developers are not trained to do so is just a reflection of our field's terrible progress re: education devs on secure app dev.

Leaving this to the user leaves the vast majority of users unsafe. This is an unacceptable state.

Why should an application developer implement a sandbox? That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail. It is also untrustworthy and insecure, since after all you don't trust the application. If an application is responsible for sandboxing itself it can also choose not to sandbox itself properly if it wants to do harm.

There is no way around you either taking care of that yourself or you choosing an operating system that enforces it for you, like Qubes OS.

> Why should an application developer implement a sandbox?

Because they are the ones who understand the necessary capabilities of their program and the ones who have access to the source code...

> That's a huge waste of time and it's much more efficient if the operating system or the user enforces it instead by using existing sandboxing technologies like firejail.

Actually it's a far better sandbox when built into the program. And it doesn't leave users relying on installing arcane operating systems or becoming technically savvy.

> It is also untrustworthy and insecure, since after all you don't trust the application.

No, trusting the application is implicit since it's installed by the user. The sandbox exists to protect against a compromised application.

I, the user, do that. It's not the app's responsibility.