[Rd] Scanning a R script for potentially insidious commands

Simon Urbanek simon.urbanek at r-project.org
Wed Dec 19 19:10:43 CET 2012


On Dec 19, 2012, at 1:09 PM, Gabriel Becker wrote:

> Simon,
> 
> I don't really have a horse in this race (as I said I didn't write sandboxR), but it seems like if you control library (to prevent "untrusted" packages, specifically including things like Rcpp and Rffi), and dyn.load the executing arbitrary compiled code issue can be curtailed. If I'm wrong please let me know, I'm always looking to learn.
> 
> I assume XXXX in your example was some C code you whipped up and then loaded using one of the methods above? Or a .Call to an existing internal R function?
> 

No, it's pure R code, I just didn't want to put the exploit on the list ...

Cheers,
S


> ~G
> 
> On Wed, Dec 19, 2012 at 9:12 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> On Dec 19, 2012, at 11:21 AM, Gabriel Becker wrote:
> 
> > See also: https://github.com/Rapporter/sandboxR
> >
> > sandboxR (not written by me) is a proof of concept for security inside R
> > (as opposed to security outside R as discussed above) via evaluating all R
> > commands in a specialized security environment (R environment that is)
> > which contains safe replacements for blacklisted functions.
> >
> 
> It is a good example of false security. For the reasons mentioned before this doesn't work and can be circumvented:
> 
> > sandbox("XXXX('tail /etc/group')")
> _developer:*:204:
> _locationd:*:205:
> _carddav:*:206:
> _detachedsig:*:207:
> _trustevaluationagent:*:208:
> _odchpass:*:209:
> _timezone:*:210:
> _lda:*:211:
> _cvms:*:212:
> _usbmuxd:*:213:
> [1] 0
> 
> The problem is that you can try to plug holes (and sandboxR is trying hard to plug a lot of them), but there will always be new ones. It's simply the wrong approach IMHO.
> 
> Cheers,
> Simon
> 
> 
> 
> > HTH,
> > ~G
> >
> >
> >
> > On Wed, Dec 19, 2012 at 5:33 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
> >
> >>
> >> Jeroen has a package devoted to the sandboxing approach in conjunction with
> >> the system-level AppArmor facility:  RAppArmor.  See
> >>
> >>  http://cran.r-project.org/web/packages/RAppArmor/index.html
> >>
> >> and more details at
> >>
> >>  https://github.com/jeroenooms/RAppArmor#readme
> >>
> >> Dirk
> >>
> >> --
> >> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
> >
> > --
> > Gabriel Becker
> > Graduate Student
> > Statistics Department
> > University of California, Davis
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> 
> 
> 
> 
> -- 
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
> 



More information about the R-devel mailing list