ShadowRealm Integration #42528
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
|
What sort of guarantees do we get in terms of isolation? Do we have a proven (as in formally) sandbox that is unescapable except with side-channels? This enables some interesting use cases and I'm wondering if this means we can relax our "Do not use this for security" bits on vm (and build it on top of this) |
The isolation guarantee of the ShadowRealm is about the isolation of the object graphs. This indicates that we will not accidentally exposes JavaScript vulnerable built-ins to the ShadowRealm, like what let ctx = vm.createContext();
let fn = vm.runInContext('...', ctx);
fn({}) // <= the function created in the vm can get access to the OUTER `Object` and hijack its methodsHowever, since the code evaluated in the ShadowRealm is still sharing the heap with the code outside of the ShadowRealm. This means it is still vulnerable to Spectre, etc. For Host APIs exposed in the ShadowRealm, technically, we are expecting them to be side-effects free -- and thus can not be utilized to initiate attacks on the host environment. (@benjamingr I assume you closed the issue accidentally? I'm reopening this) |
Yes, sorry. |
Yeah I think side-channels in general are outside of scope of things like ShadowRealm - even if we run it in a worker (or in a container in a worker that's still not enough to mitigate side channel attacks). IIRC @erights pointed out there is a way to avoid side-channels: we can choose not to expose APIs (like process.hrtime) that allow time measurement (this also includes stuff like Date.now(), performance.now(), some parts of http and a bunch of others). |
The SES proposal is designed to deal with all that sort've stuff, Note that the web is already planning on exposing all sorts of things like high resolution timers into |
What is the problem this feature will solve?
ShadowRealm is a TC39 stage 3 proposal that introduces a new built-in to provide a distinct global environment, with its own global object containing its own intrinsics and built-ins. Its ability is similar to Node.js built-in
vm.Context, however, ShadowRealm provides a stronger guarantee on object exchanges across realm boundaries.As the ShadowRealm is a distinct global environment, Web integration is also under work (Like 1) to define which web APIs should be exposed in the ShadowRealm so that people can still utilize the Web APIs that still useful in the ShadowRealm. The line generally draw between the APIs that should be exposed in the ShadowRealm or not is generally if the APIs are side-effect-free to the host environment.
What is the feature you are proposing to solve the problem?
ShadowRealm is currently under active development in v8. The design doc of the Host API could be found at here. I'd believe in Node.js we may need to be able to re-evaluate the native modules in the ShadowRealm so that their object graph is not tangled with the main context, to not violate the principle of the design. /cc @nodejs/startup
I'd believe there are a bunch of modules that are useful and can stand in the line of side-effect-free, like EventEmitter, Stream, URL, etc. Also, the Web APIs that are available in Node.js like WebStream could also follow the Web specs to be exposed in the ShadowRealm. We may need to list all the possibilities that can be available in the ShadowRealm, and eventually make them available in the ShadowRealm.
/cc @nodejs/vm
The text was updated successfully, but these errors were encountered: