Ralph, > FWIW: I haven’t seen it before. >
Good to know. > > Not sure I understand the issue, but I have no knowledge of Jupyter or why > you are using it. From what I can see, it appears that your choice of tools > may be complicating your solution - I’d suggest perhaps focusing on solving > the problem rather than trying to force-fit your current tools, but that > presumes you don’t have some particular attachment to those tools. > No attachment to particular tools. This is a greenfield project. As to Jupyter, it's fairly simple. JupyterHub launches Jupyter in a Docker container with the user's directory, e.g. /var/nfs/jupyter/robnagler gets mounted /home/docker-user. Then the user can bring a up a terminal and work within the container as if they ssh'ed into the container, but without having to run ssh. Think of JupyterHub as way to provide login nodes without having a corresponding Unix user. > > That isn’t the security hole - the issue is that Docker doesn’t prevent > the user from taking privileged state, which means the user can become > root. Yes, it is within that container - but the network and other 3rd > party services can be vulnerable. Cgroups doesn’t really solve that problem > as it still thinks the user is the one you originally set for the > container, and constrains resources that way - but it doesn’t do > authentication protection. > I think user namespaces <https://docs.docker.com/engine/reference/commandline/daemon/#daemon-user-namespace-options> (Docker 1.10) helps mitigate privilege escalation/container escape issues. You can become root in the container, but outside the container, you are some other user, like NFS's root_squash. Docker by default does contain the network and other devices. I don't really know what MPI would require, but it seems to work with TCP sockets, which don't allow spoofing. One thing I'm assuming with all this is that people who run containers on Docker Hub, Travis, Terminal.com, etc. have similar problems. They are running jobs on behalf of web users (like our problem) as a single unix user id. Docker Hub runs containers as root to build images so they must be able to lock down containers well enough. Another thing we can (and probably should) do is verify the images have no setuid files. I think this would eliminate a lot of the privilege escalation issues. Rob
