On Dec 19, 2012, at 1:10 PM, Simon Urbanek wrote:
> 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 i
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 execut
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
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 envi
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 replacement
On Dec 19, 2012, at 7:38 AM, Joris Meys wrote:
> On Wed, Dec 19, 2012 at 1:02 PM, Jan T Kim 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.
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...
On Wed, Dec 19, 2012 at 1:02 PM, Jan T Kim 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
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
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()
On Dec 18, 2012, at 12:48 PM, Etienne Sévin wrote:
> Hey all,
>
> We are building a R connector for our web application.
> The user can upload a script so it can be executed on the server.
>
> Is there a way to scan the script for insidious commands (writing on the
> disk for example) and pur
11 matches
Mail list logo
