[R-pkg-devel] Sanitize Input Code for a Shiny App

[Matthias Gondan]

For the record, here's the documentation of the Prolog sandbox,

https://www.swi-prolog.org/pldoc/doc/_SWI_/library/sandbox.pl

You get an idea of the implementation by clicking at the ":-" icons. It does not seem too complicated, but I might be too optimistic. It would be very nice to have such a thing in R, and I would be willing to help if someone takes the lead.

Best regards,

Matthias

> Am 01.03.2023 um 01:52 schrieb Bill Denney <bill using denney.ws>:
> 
> Hi Simon and Ivan,
> 
> Thanks for confirming my suspicions.  The most common case for our code
> would be generally trusted users within an organization.  So, the main
> threat is lower.  But, there may be scenarios that also allow use outside
> organizations.
> 
> I think that in the end, we will likely do some minimal sanitization of the
> input, but then we will also ensure that we do anything in a container with
> limits applied from the outside, too.
> 
> Thanks,
> 
> Bill
> 
> On Sun, Feb 26, 2023, 4:57 PM Simon Urbanek <simon.urbanek using r-project.org>
> wrote:
> 
>> Bill,
>> 
>> the short answer is you can't limit anything at R level. Any attempts to
>> create a list of "bad" commands are trivial to circumvent since you can
>> compute on the language in R, so you can construct and call functions with
>> trivial operations. Similarly, since R allows the loading of binary code
>> the same applies for arbitrary code. So if you give users access to R, you
>> should assume that is equivalent to allowing arbitrary code execution.
>> Therefore all you can do is limit the resources and reach - as you pointed
>> out using a container is a good idea so each session is only limited to a
>> single container that goes away when the session ends. Similarly you can
>> restrict main parts of R and the system to be read-only in the container.
>> 
>> In practice, that's why real analytic systems are about provenance rather
>> than prevention. For example, in RCloud all code is first committed to a
>> git repository outside of the container before it can be executed, so
>> malicious users can do whatever they want, but they cannot hide the
>> malicious code they used as the container cannot manipulate the history.
>> 
>> As for package installation - again, it's impossible to prevent it in
>> general unless you make everything read-only which also prevents the users
>> from doing meaningful work. So the real question what do you want to allow

	[[alternative HTML version deleted]]