To what degree can users modify the notebook environment from within a Jupyter notebook?

[Hussein Elgridly]

Hi folks,

I'm thinking of writing a Jupyter server extension to provide an endpoint that another service in our ecosystem would call.

In our environment we're proxying all HTTP traffic between the user and the notebook, so we could plausibly prevent the user hitting our new endpoint if we wanted.

I see from the Jupyter server API that users can access and update the Jupyter configuration. This leads me to a few questions:

1. Does this extend to editing NotebookApp.nbserver_extensions, i.e. editing the list of installed extensions? Would users therefore be able to disable our server extension, or worse, replace it with one of their own?

2. What would users miss out on if we blocked access to the /config endpoints?

3. Aside from hitting /config, are there other ways that users can mess with the server environment? Should we, as administrators of a Jupyter server, consider the entire server and notebook environment open to modification by users -- or is their power to tinker limited in some way?

Thanks,

-Hussein

[Roland Weber]

Hello Hussein,

in a typical Jupyter installation, users have write access to the configuration files and kernel specs. They can wreak all kinds of havoc there. Even if you stop them from messing with configuration files and kernel specs, they may be able to install at ~/.local/ different versions of Python packages, or site-customization files, which are loaded by the Jupyter server on startup. Unless you've taken special precautions, like running the Jupyter server in a read-only environment and without access to the user's home directory, it's safest to assume that it is completely open to modification by users.

I think notebook server extensions are loaded when the server is started. User modifications to the config file will not take effect until the server is restarted. If you're always starting the notebook server from clean config files, for example in a fresh Docker container, there are no user modifications. But if your config files are persistent, the user modifications kick in the next time the server is started.

If you prevent users from modifying notebook server extensions, they will not be able to install notebook extensions on their own, which can be annoying: https://stackoverflow.com/a/45961414/5629418

So you have a choice of letting users install their own notebook server extensions and disabling yours, or to block them from changing notebook server extensions at all.

I'd love to learn that I'm wrong though... :-)

cheers,

  Roland

[Hussein Elgridly]

Hi Roland,

We are in fact spinning up Jupyter in a Docker container, so a) users can't restart it and b) if they break their environment, too bad. They can start again with a fresh instance and not mess it up this time :)

If you're right in saying that user modifications to the config file only take effect on a server restart, I think that's secure enough for us.

Though: can they mess with the running Jupyter instance programmatically? If they can do something like import IPython.NotebookApp and monkeypatch the URL handlers, that would be baaaaad.

Thanks,

-Hussein

[Roland Weber]

They can access the address space of the Jupyter process through the /proc pseudo file system, can't they? I cannot tell how much effort it would be to mess with the process without crashing it. Given enough motivation, I'm sure it can be done.