New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X11 is horribly insecure, each subuser should get its own X11 server in a container. #31
Comments
See #29 |
Rather than VNC, we will likely use x11 via SSH with x11-security extensions enabled. |
I've tested running containers via |
On the other hand, security is a primary goal for subuser. Also, using ssh could allow an admin to start sessions, while multiple restricted users connect into it. These are very good reasons for using ssh. If using it as a system for multiple sessions, then the name 'subuser' might become a relic. :) Personally, I want to use docker on a single user machine, and for untrusted apps like skype and flashplayer. So my concerns tend to lean a little heavier towards performance over security. Given that subuser was designed for the purpose of security, ssh (or some other secure solution?) is probably the way to go. |
@Sepero luckly, we can always provide both options. |
Alternatively, you could experiment with Wayland and running X11 applications inside of XWayland. |
@ToBeReplaced I initially got the idea for subuser when I watched a video presentation on wayland and learned about the fact that it allows for x11 server isolation. I think that when wayland gets popular it may be a great solution for this problem. However, x11ssh is here today, and so I want to support that to. |
So in order to fix this bug, we need to launch a service (the contained X11 server with an XPRA server or SSH server) when a client(a subuser process) starts and then stop that container when all clients have stopped: Unfortunately there are two race conditions that a naive implementation faces.
So what is the best way of avoiding this kind of race? |
One way to avoid such race conditions would be to have a always on subuser daemon. The daemon would be single threaded and read connection and disconnection signals one by one from a socket. Perhaps it would sometimes stop the X11 container for a given subuser and then imediately restart it, but this wouldn't happen very often and wouldn't really matter. The biggest problem with this approach is that always on daemons are evil and should be avoided at all costs because they waste ram and add to runtime system bloat :/. |
So rather than using an always on daemon, each subuser application which needs it's own X11 server will get a lock file which records the number of running process. Since the lock file can only be opened by one client at a time, this enforces "single threaded-ness" and therefore does not suffer race conditions. The logic is that when a client is first created it opens the lock file. Increments the counter. If the counter was zero before the increment it starts the X11 server container. It then connnects to the X11 server container. When a client closes the X11 server container opens the lock file and decrements the lock file. If the counter is zero after the decrement, then it stops itself. The only problem with the second part of this logic, is that the X11 server container probably has no way of getting informed when when a client container stops. This probably means that we need an extra process outside of the X11 server container running on the host system which is able to monitor the docker daemon or otherwise find out when client containers stop. This adds a bit of extra complexity to the whole system, and probably a bit of overhead as well. But I believe it will be well worth it in the end, because the world really does not need any more always on daemons. |
Fixed, yay!!!!
|
The contained X11 servers should be accessible to the main X11 server via xpra.org, VNC, or wayland.
The text was updated successfully, but these errors were encountered: