RStudio Pro and chroot

rstudioserverpro
security

#1

I am trying to set up RStudio Server Pro in an organisation on a centos 7 server.

Security is not willing to validate the solution as users can run linux commands (with R functions system and pipe) and can copy or read system files (/etc/rstudio/* for example).

They want the user to be chroot jailed: the user should only access it's home files, he should only be able to run a minimal set of commands (i.e. head, tail, gunzip).

Has anyone experienced and solved such a use case?


#2

This is a great question, and is always unfortunate. It definitely seems feasible at some level, although I have not seen it done. The set of minimal commands available will have to be bigger at a minimum (i.e. R will need to be included). I am curious to see how it works - I presume there are a handful of commands that are necessary to the system running successfully.

Is there any particular thing that the admins are concerned that people will do? An organization that doesn't trust its employees is not trusting its most valuable asset. There is usually a line at which you say: "We trust you with this much authority." It seems like that line has been drawn a bit too restrictively - the user of a linux machine generally can't do much harm, given the appropriate system permissions. I.e. this is not a system where you would expect malicious users... they're your employees! Further, RStudio Server Pro has code auditing, so they could audit and see what code is being executed.


#3

Yes, I confirm that R needs also to be jail root, the necessary set of command is inded significant. But we have not succed to run RSP with this config.
It seems it can not be done.

Is there any particular thing that the admins are concerned that people will do?

Yes, data are very sensitives, users can't share data nor copy data outside or their home directory.

[...] this is not a system where you would expect malicious users...

This is a system where people from the organisation and people outside the organisation will access RStudio.
Regulation authority following french laws want to be sure there will be no data leak.

RStudio Server Pro has code auditing, so they could audit and see what code is being executed.

Thanks, that's interesting. When user is "sourcing" an unsaved script, we can only read the following (not the code that is run)

source('~/.active-rstudio-document')

As a result, in the audit table, column data is empty. I guess a solution is to overwrite source and make sure echo is always set to TRUE. Any other suggestion would be welcome.
That does not trace everything but this is a step forward.

From your answers and questions, I understand system permission is the recommended way to secure the environnement with a centos OS and that chrooting users is not recommended.

Thanks


#4

Very interesting! Thanks for the response! I would definitely be interested to hear about your progress on this as you dig in.

I would definitely lean the route of system permission, and maybe setting up separate machines for internal / external developers if that makes sense.

I have to admit I am not super familiar with chrooting. Any possibility you'd be up for sharing some of the commands you have executed? There may be a chance other sets of eyes could help figure something out.

To be clear, the rserver service will need to be privileged so it can spawn processes as other users, but it is possible that the user permissions could be locked down a great deal and the trick is just finding out what "minimal set of commands" is necessary to execute an R process on RStudio Server Pro.


#5

I don't know what @davidgohel's use case is, but I know that virtual labs are getting more popular in academia. For example, instead of sending a researcher potentially sensitive health data and getting them to ensure they store, analyse and, later, archive or destroy the data securely, you invite the researcher to use a managed analysis environment (the virtual lab) that has both access to the data and the computational resources to analyse it. I imagine RStudio Server Pro would be attractive for this sort of application!


#6

I will try to find time soon to show the used code