feat(ses): hostEvaluators lockdown option

[leotm]

Refs: #1891 (tracker), tested on #2334, Endo Sync: 2025-01-29

TODO

• add new lockdown option
  • legacyHermesTaming: safe (default), unsafe
  • hostEvaluators: all (default), none (csp), no-direct (hermes)
  • fail on safeEval (default) and no-direct (hermes) early
    • i.e. require unsafeEval and no-direct on hermes
  • add assertions
  • add warnings
  • update types
  • update ses/error-codes/SES_DIRECT_EVAL.md
  • update lockdown.md
  • refactor assertDirectEvalAvailable (return results, now used for further assertions)
  • ensure backwards compatibility (no option provided)
    • before: worked under CSP (allowed in assertDirectEvalAvailable try/catch)
    • after: { hostEvaluators: 'none' } now explicitly required
    • endo sync: 4th option undefined, warn to use the new option
  • attempted to disable compartment-shim when bundling ses for hermes (not trivial)
  • disable: globalThis Compartment and testCompartmentHooks
  • disable compartmentInstance.evaluate instead of deleting compartment
    • makeCompartmentConstructor setGlobalObjectEvaluators safeEvaluate is the default (no evalTaming yet)
    • CompartmentPrototype.evaluate returns compartmentEvaluate safeEvaluate is the default (no evalTaming)
    • endo sync: throw error on usage
• test on hermes
  • evalTaming: noEval/safeEval/unsafeEval
  • hostEvaluators: all/none/no-direct
  • post-lockdown: eval(42), eval('42'), Function('return 42')()
• check prev test branch (below)
• fix typos

Follow-up: new Compartment() fails on removeUnpermittedIntrinsics at

• Tolerating undeletable intrinsics.%CompartmentPrototype%.importNow.prototype === undefined
• Uncaught TypeError: property is not configurable

test branch https://github.com/endojs/endo/tree/ses-hermes-p2 (from #2334)

• yarn build:hermes bundle ses for hermes
• yarn test:hermes run ses/test/_hermes-smoke.js

Hermes eval behaviour on bin/hermesc (standalone compiler) and bin/hermes (vm, eshost)

// Hermes direct eval cannot access or modify variables within its closure scope (sloppy and indirect)

eval = globalThis.eval; // remains direct eval, compiler: "error: invalid assignment left-hand side"

// calling globalThis.eval(...) uses indirect eval

// calling eval on Hermes VM emits: "warning: Direct call to eval(), but lexical scope is not supported."

print(eval(1 + 1));
print(eval("1 + 1"));

function a(eval, TEST) {
  // compiler: "error: cannot declare 'eval'"
  eval("TEST=true");
  return TEST;
}
print(a(eval, false)); // vm: false

function b(eval) {
  // compiler: "error: cannot declare 'eval'"
  var TEST = false;
  eval("TEST=true");
  return TEST;
}
print(b(eval)); // vm: false

function c() {
  var TEST = false;
  eval("TEST=true");
  return TEST;
}
print(c()); // vm: false

function d() {
  var TEST2 = 42;
  return eval("TEST2");
}
print(d()); // ReferenceError: Property 'TEST2' doesn't exist

// Note: eshost only runs bin/hermes (vm), not bin/hermesc (compiler)

[naugtur]

IF an environment is lacking the direct eval support, we won't be able to provide the compartment evaluation capabilities, but we can have a constructor that creates instances with fresh tamed copies of compartmentInstance.globalThis that we use in bundling (lavamoat's webpack and browserify) and might want to use in Hermes in the future. So I'm not 100% sure if we want to delete Compartment or make evaluation related functionality throw a descriptive error from the implementation that depends on direct eval.

[leotm]

so currently deleting compartment breaks hermes on webpack (repack)? 😅

[leotm]

and only disabling compartmentInstance.evaluate would be more ideal?
to still be able to construct instances (with fresh tamed copies of compartmentInstance.globalThis)

[leotm]

i see, bundling ses without compartment-shim proved difficult, partial compartments seem a better alternative

endo/packages/ses/src/make-safe-evaluator.js

Lines 45 to 46 in 3f9b909

	// Creating a compartment should be possible in no-eval environments
	// It also allows more global constants to be captured by the optimizer

[naugtur]

AFAIR our conclusion was, as long as we don't want compartmentalization, the indirect eval used for tamed eval and tamed Function would transparently work and we don't need to throw an error when that's used.

[leotm]

this was more a refactor since the arg name and JSDoc both assume safeEvaluate which is incorrect (it could be noEvaluate)

[leotm]

regardless of compartmentalization, the (hermes) indirect eval used for tamed eval (string args only) and tamed Function doesn't transparently work, since safeEval eventually calls makeSafeEvaluator, which throws Hermes' ambiguousUncaught SyntaxError: 2:5:invalid statement encountered, so i think it's better to throw an error that safeEval requires an engine that supports with statement

[leotm]

undefined as default value not currently supported by getEnvironmentOption