Graal: Document sandboxability

Created on 25 Sep 2018  路  7Comments  路  Source: oracle/graal

The polyglot api allows a host application to compile code in other languages and call it. It isn't clear, however, whether this code can be sandboxed. For many scripting applications you want to run untrusted code and limit what it can do: access disk, access the network, access functions in the host language.

There is some mention of using Graal to stop malicious code (https://www.graalvm.org/docs/graalvm-as-a-platform/embed/#reliable-timeouts-for-malicious-code). More detail would be helpful.

documentation tracking truffle

Most helpful comment

Which is it? Can GraalVM be used to implement a robust sandbox for untrusted code? Or at least, is that an intention and priority for this project?

It is a high priority item for this project. We call it "less trusted", as currently with guest code it is possible to negatively impact the host vm, like with out of memory errors. We have plans to address these issues, such that in the future we can call it "untrusted". We are working towards that goal, but I cannot guarantee whether it is going to fully work out.

Here are some of the features I think are necessary towards that goal:

1) CPU Time Limit (ships with 20.0 CE)
2) Retained Memory Size Limit (in progress)
3) Maximum Allocation Size Limit (in progress)
4) Guest Stack Limit
5) Code Loading Limit

Note that some of these features might become EE only.

Here it seems like the conclusion is that GraalVM is not appropriate for sandboxing (at least insofar as this document is not claiming that GraalVM is one of those appropriate isolation primitives):

As mentioned before, currently guest applications can impact the host VM in malicious ways. Afaik the Chrome browser currently uses process isolation as isolation primitive.

All 7 comments

Tracking internally as Issue GR-20915.

In the meantime we have added more documentation about access restrictions:
https://www.graalvm.org/docs/reference-manual/embed/#access-restrictions

And we have added a Security Guide that should answer most security related questions:
https://www.graalvm.org/docs/security-guide/

Please reopen if you think that we still need more detail in a certain area.

(I can't re-open, but I did still have some questions)

The execution context for these guest applications can be created with restricted privileges, to allow for the execution of less trusted guest applications. For example, an embedder writes an application server (the host application) that runs JavaScript guest applications from a less trusted source. GraalVM offers features to limit the privileges of the guest application to some extent.

@chumer can you explain what "less trusted [code]" means?

Here I am led to believe that GraalVM might be a good building block for developing a sandbox:

Developers that implement security controls for their applications (such as access control) in code that is being run by GraalVM can rely on the correct execution of instructions. Incorrect execution of security-critical code running on top of GraalVM that allows to bypass such a security control is regarded a security vulnerability.

Here it seems like the conclusion is that GraalVM is not appropriate for sandboxing (at least insofar as this document is not claiming that GraalVM is one of those appropriate isolation primitives):

If untrusted and potentially malicious code is to be executed, we recommend GraalVM customers who have an immediate requirement to execute untrusted and potentially adversarial code, adopt the appropriate isolation primitives to ensure the confidentiality and integrity of their application data.

Which is it? Can GraalVM be used to implement a robust sandbox for untrusted code? Or at least, is that an intention and priority for this project?

Which is it? Can GraalVM be used to implement a robust sandbox for untrusted code? Or at least, is that an intention and priority for this project?

It is a high priority item for this project. We call it "less trusted", as currently with guest code it is possible to negatively impact the host vm, like with out of memory errors. We have plans to address these issues, such that in the future we can call it "untrusted". We are working towards that goal, but I cannot guarantee whether it is going to fully work out.

Here are some of the features I think are necessary towards that goal:

1) CPU Time Limit (ships with 20.0 CE)
2) Retained Memory Size Limit (in progress)
3) Maximum Allocation Size Limit (in progress)
4) Guest Stack Limit
5) Code Loading Limit

Note that some of these features might become EE only.

Here it seems like the conclusion is that GraalVM is not appropriate for sandboxing (at least insofar as this document is not claiming that GraalVM is one of those appropriate isolation primitives):

As mentioned before, currently guest applications can impact the host VM in malicious ways. Afaik the Chrome browser currently uses process isolation as isolation primitive.

Since version 20.0 is already released and is the current version, is there already support for any of the items mentioned above(CPU Time limiting for example). If yes, any instructions/docu on how to enable this feature would be appreciated.

Hi, any update on this feature? Did some of it made it to the 20.1.0? Did not found it in the release notes.

Hi, I see that CPU time limit feature is in progress (_'We need to solve GR-18742'_) https://github.com/oracle/graal/blob/706a8d435820210268d1516110ad1a7954ff73b1/sdk/src/org.graalvm.polyglot/src/org/graalvm/polyglot/ResourceLimits.java#L225

Can you, please, give an update when the feature can be in production state?
Thank you!

Was this page helpful?
0 / 5 - 0 ratings