1. That's a big "if"; I'm fond of docker precisely for fixing software availability issues.

2. It's diminished, but it still provides significant protection, since the containerized program still can't see the real filesystem or process table without going through X or something networked. That's still pretty significant; it would, for instance, protect against a Firefox zero-day that was being used to read people's private SSH keys (not a hypothetical; that incident is what pushed me personally to start sandboxing my browser).

Backup there. I somehow have not heard about this. What was the vector? What was the exposure? E.g. have I leaked the contents of ~/.ssh to some (hopefully small, at least) subset of sites I've visited? Where can I learn more?

I don't deny that in theory someone could deploy a Firefox zero day that steals ssh keys and that having an abnormal setup via docker could throw a wrench in that, but you are essentially relying on obscurity of your setup which is not an acceptable approach - in the same way that the obscurity of TempleOS would not be a good security approach.

Where beginners in security wrongly rely on it entirely

Then intermediate experts proudly proclaim that it's not acceptable

Then expert experts realize it's an excellent part of defense in depth.

-

I mean I know it's a hyperbolic example in your comment, but do you really think leveraging the obscurity of TempleOS wouldn't be an extremely potent way of dodging 99.99999% of malware in existence?

Forcing a tailored attack to breach your isolation is already miles ahead of just running it on your desktop and is most certainly an "acceptable approach", even if it's not infallible.

For example: if you're hosting a self made shopping cart versus an open source/commercial product, there's probably a higher risk of being vulnerable to SQL injections. It's conceivable that open source and commercial offerings have been beaten on more and as a result hardened against more attack vectors.

Of course to your point, it means that you're not vulnerable to a zero day that impacts many deployments. I imagine the shops that made their own logging library were quite pleased with themselves when the log4j vulnerabilities came out.

My point being that it's not a simple calculus, and it's really hard to evaluate the relative risks of one versus the other. It's probably best to look at the cost of implementing and maintaining security through obscurity and using that as a litmus test for if it's reasonable or not.

Running something on a non-standard port has a very different cost than making your own operating system.

https://www.x.org/releases/X11R7.6/doc/xextproto/security.ht...

If you pass the GPU device node through to an LXC container I believe you can run an X or Wayland server fully inside of it but I'm not sure if changing ttys will work correctly because you might need access to more than just the GPU to handle the handoff with the kernel correctly.