From simon.urbanek at r-project.org  Wed Dec 19 16:46:52 2012
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 19 Dec 2012 10:46:52 -0500
Subject: [Rd] Scanning a R script for potentially insidious commands
In-Reply-To: <CAO1zAVaXwrt_f1LN29kJz-2XvoOYn5rz-EuuHnqYfXWrL2sJPg@mail.gmail.com>
References: <50D06614.9060404@epiconcept.fr>
	<C388E3C2-611A-4717-8049-D72867AB8BCB@gmail.com>
	<CAO1zAVbqQXsBEz7Uvdjqi0FxE2NxMb3fTZ5MuEFgn3KSaLb_xw@mail.gmail.com>
	<20121219120210.GA4036@paxarchia.galaxy.uni>
	<CAO1zAVaXwrt_f1LN29kJz-2XvoOYn5rz-EuuHnqYfXWrL2sJPg@mail.gmail.com>
Message-ID: <916A272F-6A1D-47DA-AA77-7D64CE0CEE5B@r-project.org>

On Dec 19, 2012, at 7:38 AM, Joris Meys wrote:

> On Wed, Dec 19, 2012 at 1:02 PM, Jan T Kim <jttkim at googlemail.com> wrote:
> 
>> On Wed, Dec 19, 2012 at 12:39:21PM +0100, Joris Meys wrote:
>>> The safest way to prevent attacks using an R connector, is managing the
>>> permissions for the application on your own server. We do that with the
>>> RStudio Server application we have running. You have to take into account
>>> that R allows for many interactions with the system. Also file(), dir(),
>>> unlink() and all sys. functions have the potential to screen and possibly
>>> alter your system. Not only system() and eval() pose a security
>> problem...
>> 
>> just out of curiosity, how do you disable these functions?
> 
> 
> You got me wrong: We don't disable these functions, we just don't give the
> R instance that's executing the file any permissions on the system. So
> trying to run any function that wants to access the system only results in
> error messages. I believe we did that by creating a specific user account
> and linked that to the R application behind the interface. But sandboxing
> (as you mentioned) is just as good.
> 

Creating a *specific* user is not enough as instances can affect each other (i.e. any job running on such system is in jeopardy - you never know if your results were modified by a malicious process). Rserve allows separate uid/gid per connection so that's one way to tackle that - it also makes the separation easier. As Dirk pointed out on Linux there is AppArmor and sandbox on OS X if you want to limit what the user can do.


And, indeed, trying to filter commands is not the right way as it's trivial to circumvent - anyone with access to R has the capability to run arbitrary native code with .C/.Call and you can't disable that without making R unusable.

Cheers,
Simon



> -- 
> Joris Meys
> Statistical consultant
> 
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
> 
> tel : +32 9 264 59 87
> Joris.Meys at Ugent.be
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



[Rd] Scanning a R script for potentially insidious commands
Simon Urbanek