4 ms·

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 th

• joombaga 5y ago
  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.
  • 0x0 5y ago
    Nobody runs more than one X server. And the X server isn't involved with other localhost services.
    • joombaga 5y ago
      I don't intend to run more than one X server. Most of my GUI applications don't use X.
    • d110af5ccf 5y ago
      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.
  • remram 5y ago
    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.
• yjftsjthsd-h 5y ago
  > 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).
  • beardog 5y ago
    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.
    • BoorishBears 5y ago
      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.
      • chrsig 5y ago
        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.
• tedunangst 5y ago
  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.html https://www.x.org/releases/X11R7.6/doc/xextproto/security.ht...
  • remram 5y ago
    You're in a thread about mounting $HOME/.Xauthority and /tmp/.X11-unix in the container
• ranger_danger 5y ago
  All X programs can already log all other apps' key presses.
  • naikrovek 5y ago
    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?
  • remram 5y ago
    The original article uses a separate X server with VNC. So those can't.