Hacker News Reader

Comment by remram | Hacker News Reader

This has less isolation. The container has full access to your X server and can record your screen or log all key presses, for example. It also has access to the host's network interfaces, and can access services bound to localhost (even if firewalled). There is little point in running software this way, if the software is available on the host.

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`

View on HN

> There is little point in running software this way, if the software is available on the host.

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).

Using it for fixing availability is fine, but I disagree that it provides protection.

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.

I feel like security through obscurity is the most prominent example of the Dunning-Kruger effect

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.

There are quite a number of vectors that are activated similarly regardless of large swaths of the implementation.

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.

>Firefox zero-day that was being used to read people's private SSH keys

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?

https://www.rapid7.com/db/modules/auxiliary/gather/firefox_p...

It was in 2015. Mozilla's post: https://blog.mozilla.org/security/2015/08/06/firefox-exploit... and HN discussion at the time: https://news.ycombinator.com/item?id=10021376

The container should only have access to the server's keyboard input if you give it the magic cookie to do so. If you want a secure container, you would only grant limited permissions.

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

You're in a thread about mounting $HOME/.Xauthority and /tmp/.X11-unix in the container

The container would only be able to record the screens or key presses that occur in the same xserver, right? I never thought about access to localhost services. I'm guessing there's some xserver configuration that could prevent that.

Nobody runs more than one X server. And the X server isn't involved with other localhost services.

I don't intend to run more than one X server. Most of my GUI applications don't use X.

Wait I thought distros ran one X server per logged in user account and put them on different ttys. Out of the box on Ubuntu I can log in as two separate users simultaneously and switch between those unlocked sessions as well as the login screen by changing the tty.

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.

The parent's setup makes the host's X server socket available to the container, so there's only one X server in that case. In the article, they run a separate X server, which offers some isolation as you note.

All X programs can already log all other apps' key presses.

The original article uses a separate X server with VNC. So those can't.

I can’t find a source for this. I believe this to be true, but I can’t find evidence of it. Do you know of one?

Reply on news.ycombinator.com