-
Notifications
You must be signed in to change notification settings - Fork 147
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
README: warn about unlimited local network access #359
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@consideRatio To elaborate a bit, jupyter-server-proxy starts applications which then usually listen on localhost ports. jupyter protects the path to 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:
|
Ah its a lot clearer to me now @ryanlovett, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Erik Sundell <erik.i.sundell@gmail.com>
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. |
@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 |
@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. |
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