Integration with Shadow Realms?

[lukewarlow]

I'm unfamiliar with shadow realms as a whole but I see that it introduces some form of script evaluation, does this need to be covered by Trusted Types like eval and Function?

[lukewarlow]

Based on tc39/ecma262#3222 (comment) comments in here about ShadowRealms it seems that it will make use of the host callout so is probably handled by the changes to that automatically but worth keeping in mind at least.

[caridy]

Yes, we are intentionally keeping this simple, ShadowRealm.evaluate, and eval inside the shadow realm are sharing the same evaluation path, which hits the host hook, which relies on the settings object of the principal realm for validation of the provided source. That's why we put effort to make eval work with traditional CSP /TT mechanisms.

/cc @nicolo-ribaudo

[nicolo-ribaudo]

With the default policy, does this introduce a new communication channel between shadow realms and the outer realm?

e.g.

function defaultPolicyFallback(message) {
  // I have access to the message!
}

new ShadowRealm().importValue("mod.js", "x");

//mod.js
export let x;
try {
  eval("message for the outer realm :)")
} catch {}

[caridy]

It seems that we need more clarifications here. From what I remember (@mhofman keep me honest here), TT is not going to be available inside a ShadowRealm initially. Instead, we only rely on existing mechanism (CSP's hashes) to support eval/evaluate. Similarly, import and importValue to import modules is subject to CSP restrictions in the principal realm.

For .evaluate(), there were some discussions about supporting TT instances, and blobs (if allowed by CSP), so the evaluation can be carry on appropriately, specially because .evaluate is not subject to the callable boundary, (and it might belong to the principal realm), but we were waiting on TT to be finalized before finishing that part. Arguably we should be able to do it for Blob without having to wait for TT, but we haven't done that yet. For this case, I don't see a problem with the default policy because they are all operating in the principal realm (SR created inside another SR do not have access to the TT anyways). Can you confirm @nicolo-ribaudo ?

What about eval inside the SR? well, we don't have TT there yet, therefore you only have one way to bypass evaluation restrictions there, and it is via a hash. @littledan was part of that conversation from what I remember, and we said that this is ok for now. Once TT lands, we can find the right API for the SR since it doesn't have a dom, and only needs a section of the TT api surface.

[mhofman]

That all sounds about right. TrustedTypes constructor is not available inside ShadowRealm.

I am not familiar with policy fallbacks, so I think the question raised by @nicolo-ribaudo is whether any handler set in the main realm should be involved in eval() invocations inside a ShadowRealm. My intuition here is no, so that in the future we can expose TrustedTypes directly in the ShadowRealm.

My understanding is that this is safe since trusted types can only allow things that would otherwise be prevented by base CSP rules? Which confirms @caridy's point that you have to rely on hashes instead.

Of course for shadowRealm.evaluate() there should be no blocker to pass a wrapped trusted type source?

[nicolo-ribaudo]

I agree that passing the param of .evaluate() through the TT machinery of the outer realm is ok and probably desirable.

Calls to eval() and new Function inside the ShadowRealm must not go through the TT checks of the outer realm, but I also don't see a reason to not expose one day TT within the ShadowRealm.

[lukewarlow]

Yeah TT is exposed to workers so the spec would handle non window envs so no strong reason not to expose to shadow realm in future.

[caridy]

Calls to eval() and new Function inside the ShadowRealm must not go through the TT checks of the outer realm, but I also don't see a reason to not expose one day TT within the ShadowRealm.

@nicolo-ribaudo I think the question is how to differentiate them? Today, evaluate, eval and new Function are sharing the same path. If evaluate can rely on the default policy, how to prevent eval and new Function to do so?