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 <b...@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.urba...@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]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
