Programming with R on a Linux server requires users be granted local accounts. Local accounts give R programmers a fair amount of power on that server. If sandboxing R sessions could improve security, then why don't RStudio Server or Posit Workbench (previously RStudio Server Pro) sandbox R sessions?
The short answer is that R cannot be sandboxed. Like many programming languages (Python, Scala, etc), R requires a fair amount of connectivity with the system prompt at a low level. Open-source R requires that users be given a complete ssh-shell.
It's not really possible to untangle R from the way it interacts with the Linux shell. For example, R has a command called "system()" that allows you to pass through Linux commands like "ls" or "pwd". Restricting the command-line interface with the environment variables, or filtering shell commands, will typically cause RStudio Server to fail. Restricting R is akin to making it unusable.
It also means that whoever runs the R process needs a local account on the server. Service accounts won't normally suffice. With RStudio Server, we assume you will want your own identity, with your home drive mounted, and NFS/ODBC access to all your other connection points. A good R experience, therefore, requires local accounts.
RStudio Server requires root privileges because it generates new sessions on behalf of other users. You also need root privileges to install and restart RStudio Server. These root requirements are a derivative of R operating at a low level.
By default, RStudio Server allows users to open a new shell inside the IDE (see Tools > Shell). You can disable the shell to discourage users from using system commands. However, disabling it will not prevent savvy users from running the "system()" function from the R prompt.
There is no great way to sandbox R programming. If you want to program in R, you have to be willing to create local user accounts with a full ssh-shell.
Posit Workbench (previously RStudio Server Pro) does make it easy for system administrators to put limitations on resources used by the local accounts. Limitations are possible at the user or group level on memory, cpu priority, and number of sessions. More details are available in the Admin Guide.
Comments
0 comments
Article is closed for comments.