Closed revintec closed 1 year ago
@revintec, do not expect any news from me - this issue is not assigned to me (I am not responsible for this area).
sorry, typo, at-ed the wrong person
@chumer Hi, is there any update on this? thx
@chumer Hi, is this issue still being considered?
Hi @revintec. Sorry for the late response;
No, we do not have plans to implement this feature. You could implement your own security check at the entry of each method for trusted methods or create separate contexts for trusted/vs untrusted script code.
Generally, I'd not recommend running trusted and untrusted code in the same context, as JavaScript does not have any security boundaries that would enforce this separation.
For polyglot sandboxing we recently wrote some new docs: https://www.graalvm.org/latest/security-guide/polyglot-sandbox/
it's common that a language implementor have some bridge code to enable accessing deeper layer native operations(like JNI let's take javascript for example, assuming it have to write a log buffer -- named
logs
-- that is anArrayList<String>
untrustedScript:
jsBridge.appendLog("abc")
bridgeScript:window.jsBridge={appendLog(msg){logs.push(msg)},...}
logs=new ArrayList<String>();allowHostAccess(HostAccess.newBuilder().allowListAccess(true).build())
sadly is not enough, it only enables list read access but not write access. addingallowListWriteAccess(...)
could work but we can't addallowXXX(...)
for everythingof course we can make our own
class AccessableArrayList<T>{@Export void add(...)}
,ListAccessor(...)
orProxyXXX
but that requires making wrappers for almost everything, and it sure seems like an overkillis there any suggested approach to this?
what I would suggest is having separate hostAccess permissions for different scripts(like Java's
@CallerSensitive
or x86's ring0 privilege modes), e.g. addingSource.Builder.hostAccess(ALL)
, thusbridgeScript
-- which is trusted vender code -- to access all host operations while still isolatinguntrustedScript
from these operationsthanks for considering