Docker: insecure opening of file-descriptor allows privilege escalation
Oh good, yet another vulnerability from the model of retroactively changing the execution environment of a process after it's been created. We had a thread about setuid binaries a week ago, which is the most common case of this design: https://news.ycombinator.com/item?id=13312722We would all be better off if we designed systems such that some helper process, already running with the right environment / config / privileges, spawns the process for you and proxies input/output to your terminal.And (as I mentioned in the other thread) this helper process could be literally sshd. Instead of having sudo, ssh root@localhost. No weird process trees with confusing things like effective UIDs. Instead of having runc exec, ssh root@container. No file descriptors get passed that aren't explicitly forwarded over the SSH connection.Patching sshd to run over UNIX sockets without encryption and to use getpeername() for authentication is left as an exercise to the reader.