> On Jun 6, 2016, at 10:18 AM, Rob Nagler <openmpi-wo...@q33.us> wrote: > > 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.
You know what they say about “assume”…. > > 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 > > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/06/29384.php
