README: warn about unlimited local network access

[manics]

I thought there was already a warning in this repo, but it doesn't look like it. For comparison:
https://github.com/jupyterhub/jupyter-rsession-proxy#multiuser-considerations has a warning.

Closes #358

[consideRatio]

We can merge this, but I think the warning clarification was tricky for me to grasp properly - this part:

It has access to all local network services that the user has access to.

The description below was clear enough for me to feel that I understood it properly though.

Multiuser Considerations

This extension launches an rstudio server process from the jupyter notebook server. This is fine in JupyterHub deployments where user servers are containerized since other users cannot connect to the rstudio server port. In non-containerized JupyterHub deployments, for example on multiuser systems running LocalSpawner or BatchSpawner, this not secure. Any user may connect to rstudio server and run arbitrary code.

In my own words, what would I say? Hmmm...

If jupyter-server-proxy is configured to start some application for a user and expose it on some port, its exposed for whoever can access that port - which typically are all users with network access to the computer or container. Or hmmm?

Hmmm, no I don't think I understand this well enough atm to describe the warning myself. Could you elaborate or make the warning more verbose @manics?

[ryanlovett]

@consideRatio To elaborate a bit, jupyter-server-proxy starts applications which then usually listen on localhost ports. jupyter protects the path to {jupyter_url}/application/ or {jupyter_url}/port/{port} so if anyone tries to access those URLs, they will not be able to auth. However the proxied application itself may not provide any additional authentication if a user connects to localhost:{port}. In a containerized environment this doesn't matter very much because only jupyter is exposed by the container. On a multiuser system however, if someone starts an application (through jupyter or otherwise) that is listening on localhost:{port}, another user on that system can connect to that same port without intervention. For example if user1 launches cd ~/secrets/; python -m http.server 9000, user2 can curl localhost:9000 and read user1's secrets.

Users may launch jupyter on multiuser systems from the command-line, or through JupyterHub when it uses spawners like batchspawner or systemdspawner.

Potential fixes for this:

• Support proxying to a server process via a Unix socket #337, which exposes the proxied app through a UNIX socket instead of an open port
• https://github.com/ryanlovett/portwrap, which runs the proxied app in a user/network namespace so that jupyter can connect to the open port and proxy it, but nothing outside of the namespaces can reach that port

[consideRatio]

Ah its a lot clearer to me now @ryanlovett, thanks!

[consideRatio]

With the code suggestion I made, this LGTM!

Feel free to adjust it, but I think its relevant to clarify it to this degree as it is a security warning. I think those are really nice to understand, because if you don't you may not feel comfortable adopting it, alternatively feel like you end up needing to find more in depth documentation about it anyhow.

[manics]

I took out the mention of the unix socket from the README since it's not merged, so it's not very helpful to a user! We can add it to the readme when it's merged.

[im-not-an-alien-i-swear-whos-ur-leader]

@ryanlovett I like your suggestions, however, if jupyter is running in a container, what is stopping a user from using a command line in the jupyterlab instance and just accessing the hidden services in the container that way? It seems like you again have issues where you need service-specific auth such as a token, or unix sockets like you suggested.

I see that unix sockets are part of jupyter-server-proxy now so this is kind of a moot point, but I'm curious if I'm misunderstanding how the container would have helped.

Thanks

[ryanlovett]

@im-not-an-alien-i-swear-whos-ur-leader Usually jupyter-based containers are single user only, for example launched by a JupyterHub. In this case, only the one user can access the listening services in their container.

Having multiple users launch different jupyter servers within the same container that also run proxied services is not great from a security perspective, but people traditionally use containers to isolate processes.