On the other hand the use cases that the article describes can already be accomplished by Firefox's "account containers" feature or just creating another profile and running `firefox --no-remote`

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.

Here's the equivalent Dockerfile + docker-compose.yaml for convenience:

    # Dockerfile
    FROM debian:11-slim
    RUN apt-get -y update && apt-get -y install firefox-esr 
    CMD ["firefox"]


    # docker-compose.yaml
    services:
      firefox:
        image: firefox
        build: .
        environment:
          DISPLAY: ${DISPLAY}
        network_mode: host
        volumes:
          - ${XAUTHORITY}:/root/.Xauthority
          - /tmp/.X11-unix:/tmp.X11-unix

    docker-compose up

The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command.

I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.

    docker run -e XDG_RUNTIME_DIR=/tmp \
           -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
           -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY  \
           --user=$(id -u):$(id -g) \
           imagename waylandapplication

I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?

  Transports
  
  To date all known Wayland implementations work over a
  Unix domain  socket. This is used for one reason in
  particular: file descriptor messages. Unix sockets are
  the most practical transport capable of transferring file
  descriptors between processes, and this is necessary for
  large data transfers (keymaps, pixel buffers, and
  clipboard contents being the main use-cases). In theory,
  a different transport (e.g. TCP) is possible, but someone
  would have to figure out an alternative way of
  transferring bulk data.

I don't see any details about how this interacts with OpenGL, like whether indirect rendering is possible or if applications would need /dev mounted.

It could be made less verbose by encapsulating in a compose file, or by removing the env var to point into /tmp and instead using whatever the default is for the chosen image. Also it's not necessary to specify the value for an env var being passed through with the same name (I just copied from SO).

Yes, but GP's example is X over a unix socket. Not sure if that counts as network.

Because in practice it generally can't; I'm not aware of any Linux distribution not shipping their X server with `-nolisten tcp` by default.

I'm a little surprised the examples don't require fiddling with X permissions, which I always had to do when not using ssh.