jupyterhub / batchspawner

Custom Spawner for Jupyterhub to start servers in batch scheduled systems
BSD 3-Clause "New" or "Revised" License
182 stars 130 forks source link

Consider security of environment #82

Open rkdarst opened 6 years ago

rkdarst commented 6 years ago

JupyterHub makes a big deal about not allowing users to alter their own environment for their single-user server: https://jupyterhub.readthedocs.io/en/latest/reference/websecurity.html

First, I was wondering if I was missing something, because altering their own single-user would only serve HTML to themselves, so should be safe, right? (Besides, users of the same cluster could be considered "semi-trusted" but we should at least be aware of the issues)

But, assuming we need to be worried about this, we can evaluate the different spawners. For example, while setting up SlurmSpawner, I saw that by default, if --export=VAR,... is used, it will simulate a login shell and get the user's clean environment (as in, like what you might get on a fresh login) and then use that as the base, which directly allows people to do arbitrary env vars. Many spawners probably start a shell, which could evaluate config files. Basically, there are many possibilities here.

I had some mitigations:

We can't fix every spawner and every cluster's own environment. We can provide documentation for batchsystem maintainers to consider when writing their scripts. We could make some tests for others to know if they are affected.

What do you think?

rkdarst commented 6 years ago

Let's face it, right now almost every spawner evaluates shell startup files for users. SlurmSpawner did, even with --keepvars, because srun was not used which was required for this to take effect. Limiting environment then broke users' software that was being run. I don't have time to go through it all now, but let's just say that properly fixing things will require a detailed, spawner-specific analysis and will likely impact some users.

97 at least now mentions that this is a currently unsolved problem and we can't guarantee security.

rkdarst commented 6 years ago

Also if environment variables are used to authenticate as an admin, they are usually going to be passed to the user as well. req_keepvars can stop that but it's unwieldy to use. Consider this, too.