[Rd] R in sandbox/jail (long question)

Thomas Lumley tlumley at u.washington.edu
Wed May 19 18:48:23 CEST 2010



I think you'll find it's a bit more complicated than that.

Firstly, R --sandbox is pretty crippled, since as far as I can tell it can't load packages, since package loading uses gzfile().  This would include the 'stats' package.   If you can load packages you would need to sanitize all those packages, since they may contain functions that directly talk to the operating system (for example, the 'foreign' package does).

Also, most functions called by .C() and many called by .Call() can be made to overwrite memory they don't own, by passing invalid arguments, so the sandbox would only protect you from mistakes by the user and from incompetent attacks, but not from competent attacks.

     -thomas

On Tue, 18 May 2010, Assaf Gordon wrote:

> Hello,
>
> I have a setup similar to Rweb (  http://www.math.montana.edu/Rweb/ ):
> I get R scripts from users and need to execute them in in a safe manner (they 
> are executed automatically, without human inspection).
>
> I would like to limit the user's script to reading from STDIN and writing to 
> STDOUT/ERR.
> Specifically, preventing any kind of interaction with the underlying 
> operating system (files, sockets, system(), etc.).
>
> I've found this old thread:
> http://r.789695.n4.nabble.com/R-in-a-sandbox-jail-td921991.html
> But for technical reasons I'd prefer not to setup a chroot jail.
>
> I have written a patch that adds a "--sandbox" parameter.
> When this parameter is used, the user's script can't create any kind of 
> connection object or run "system()".
>
> My plan is to run R like this:
>
> cat INPUT | R --vanila --slave --sandbox --file SCRIPT.R > OUTPUT
>
> Where 'INPUT' is my chosen input and 'SCRIPT.R' is the script submitted by 
> the user.
> If the script tries to create a conncetion or run a disabled function, an 
> error is printed.
>
> This is the patch:
> http://cancan.cshl.edu/labmembers/gordon/files/R_2.11.0_sandbox.patch
>
> So my questions are:
> 1. Would you be willing to consider this feature for inclusion ?
> 2. Are there any other 'dangerous' functions I need to intercept ( 
> ".Internal" perhaps ?)
>
> All comments and suggestions are welcomed,
> thanks,
>  -gordon
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle



More information about the R-devel mailing list