On 3/1/23 07:35, Matthias Gondan wrote:
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.
From my (very quick) look at the page, my understanding is that it is
analyzing Prolog code to decide whether it is safe to execute or not. If
my reading is correct, please let me reiterate that this would not be a
good strategy for R. As Simon already wrote, R is a very dynamic
language allowing to change almost anything at runtime. It is not
possible to correctly and effectively reason about what an R program
could do. Trying to do this would be a waste of effort which might only
provide false sense of security. R cannot be made safe for such uses
this way. While enough as a show stopper, it is more than that, R
doesn't have a specification, any such tools would have to be written
against a specific R release. Also, in practice one would probably also
want to use some extension packages, which may again do anything (in
native code).
With R, I would only think of ensuring security at the machine level, as
discussed already - via virtual machines, containers (with care, not all
are sandboxes), etc. That would be much safer, much less work, and could
re-use existing technologies.
Tomas
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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
