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 <e...@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 | e...@debian.org | http://dirk.eddelbuettel.com
>>
>> ______________________________________________
>> R-devel@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
