JupyterLab extensions: hardening the user space against unauthorised access

[krassowski]

Context

After launching JupyterLab users are allowed to install extensions. These extensions may extend the single-user jupyter-server endpoints, and decide which information to expose publicly and which only upon authentication.

By default server endpoints added by extensions do not require authentication.

Value and/or benefit

1. As a data scientist I want to install an extension "performance-analysis-table" using JupyterLab Extension Manager and securely analyse my data. I am familiar with how the extensions system works and acknowledged the disclaimer message:

   

   I went as far as downloading the distribution file of performance-analysis-table from PyPI and verified the code to ensure that there it has no suspicious logic (or had someone vet it for me).

   However, a few months after installation a security advisory gets published informing that authors of performance-analysis-table missed adding @web.authenticated decorator on one of the endpoints; unfortunately this means that all of my data was exposed to anyone knowing the right link.

2. As a data scientist I also tried a few more extensions. Even though the code looked nice, they turned out to be a poor quality experiments rather than mature extensions and now I realised that they could have contained other security vulnerabilities. From now on I would like to only install mature, reviewed extensions. I would like to have provenance of the extension verified to reduce the workload needed when reviewing its code.

Anything else?

Proposed solutions:

1. Make the server use authentication by default: once jupyter-server implements an opt-in configuration option to make all endpoints require authentication (https://github.com/jupyter-server/jupyter_server issue 389), nebari should enable it to prevent users from shooting themselves in a foot by installing an extension which could unintentionally expose their data.
2. Help users verify provenance and maturity of extensions:
   • swap the default "PyPI Manager" for a conda-forge or or conda-store-based manager (which would need to be created, but it is conceptually easy) which limits the list of extensions to those which were accepted into conda or conda-forge (this does not guarantee a good quality, but often correlates with it, and certainly prevents certain kind of dangers such as typosquatting)
   • contribute to the default "PyPI Manager" so that it can display the PyPI Trusted Publisher status (see https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/), and possibly other quality indicators which are hard to game (e.g. number of stars on GitHub or number of downloads can be easily manipulated)

Additionally, some deployments might want to use already available upstream features:

• a) proxy the Extension Manager's access to PyPI to log all traffic
• b) use the allowlist or blocklist for extensions

I am not sure if there would be a value of exposing these configuration options higher up in nebari though.

Edit: by default the extension installation is disabled so it should not be blocking. Maybe the read-only extension manager should be used?