[Rd] Advice on parsing / overriding function calls

Simon Urbanek simon.urbanek at r-project.org
Thu Aug 16 17:59:56 CEST 2007

Thinking along these lines, we actually have a mechanism for  
replacing the system call (it's used by the Mac GUI to allow root  
calls) and one could think of expanding this to all critical  
operations. Clearly, there are issues (speed for example), but it  
would be nice to have a 'fortified' version of R that allows turing  
on restrictions. I don't think it's easy, but given the rising demand  
(at least in my perception), it would be interesting to see how far  
we can get.

Re filtering strings in commands - I don't think this will work,  
because you can compute on the language, so you can construct  
arbitrary calls without using the names in verbatim, so it is  
possible to circumvent such filters fairly easily.


On Aug 16, 2007, at 9:23 AM, Hin-Tak Leung wrote:

> Well, I think there are some serious use e.g. offering a web server
> for script uploaded then downloading the Rout result back...
> The issue is more about whether he wants to limit *all* file system
> access or just limiting to certain areas. For the former,
> I would set up a chroot jail and run R from within; for the latter,
> I would probably do something with LD_LIBRARY_PRELOAD to override
> all the file system accessing functions in libc directly, really.
> That would fix the problem with system(rm) and some such, I think,
> because if your entire R process and any sub-process R launches has no
> access to the genuine libc fwrite/fread/etc functions you cannot do
> any demage, right?
> Both are tricky and take time to do (the chroot jail a bit easier,
> actually...), but quite do-able.
> It depends on (1) how paranoid you are, (2) how much trouble you  
> want to
> have for yourself to achieve those restrictions...
> hadley wickham wrote:
>> What are you trying to defend against?  A serious attacker could  
>> still
>> use rm/assign/get/eval/... to circumvent your replaced functions.  I
>> think it would be very difficult (if not impossible) to prevent this
>> from happening), especially if the user can load packages.
>> Hadley
>> On 8/16/07, Michael Cassin <michael at cassin.name> wrote:
>>> Hi,
>>> I am trying to tighten file I/O security on a process that passes a
>>> user-supplied script to R CMD Batch.  Broadly speaking, I'd like  
>>> to restrict
>>> I/O to a designated path on the file system. Right now, I'm  
>>> trying to
>>> address this in the R environment by forcing the script to use  
>>> modified
>>> versions of scan, read.table, sys.load.image, etc.
>>> I can run a replace string on the user-supplied script so that,  
>>> for example,
>>> "scan(" is replaced by "safe.scan("
>>> e.g.
>>>> SafePath <- function(file)
>>> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp 
>>> [[1]])],sep="/")}
>>>> SafePath("/etc/passwd")
>>> [1] "safepath/passwd"
>>>>  Safe.scan <- function(file, ...) scan(SafePath(file),...)
>>>> Safe.scan("/etc/passwd",what="",sep="\n")
>>> Error in file(file, "r") : unable to open connection
>>> In addition: Warning message:
>>> cannot open file 'safepath/passwd', reason 'No such file or  
>>> directory'
>>> I'd appreciate any critique of this approach.  Is there something  
>>> more
>>> effective or elegant?
>>> Regards,
>>> Mike
>>>         [[alternative HTML version deleted]]
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list