compartment-mapper: makeSecureBundle with bundled runtime and no-eval

[kumavis]

previous iterations:
modify existing bundler for ses-wrapping #1437
ensure archive machinery can bundle #1436

Must:

• relies on some ses utilities being exported feat(ses): publish utils bundle #1454
• allow precompiledFunctor in ses feat(ses): allow module-instance to use a precompiledFunctor #1461
• verify tests are running censorship transforms eg dynamic import

Should:

• fix reference triangle in bundle-runtime
• reduce serialization when reading from archive
• test support of json and other modules

Could/someday:

• init/load time stats api
• support bundle splitting

[naugtur]

I'm not sure when's the good time to do it, but we should probably check functorSrc parses as JavaScript.

try {
  eval(`throw Error('valid');
  ${functorSrc}`);
} catch(e) {
 assert( e.message === 'valid')
}

It'd be the safest to do at runtime in case there's differences in parsing, but that's not something we want to do with end-users' CPUs so earlier in build process would have to suffice.

[kumavis]

consider 😈

  eval(`throw Error('valid');  ${functorSrc}`);

with functorSrc:

function Error () { /* attack payload */ }

browserify uses throw 'STOP';

[kumavis]

• src is validated when creating a bundle by entrypoint, somewhere in prepareToBundle
• added a failing test showing makeSecureBundleFromArchive not validating invalid module sources

[naugtur]

Ok, that looks solid, the only remaining concern is someone finding a way to make unziping+parsing in the runtime host result in a different module.
eg. we build an archive in Node and then run it in Hermes or some bespoke JS engine with an ASI implementation quirk or parsing bug that changes the AST resulting from the original text. That could be exploited fairly easily (after it's been found, which is the hard part) using the method I used when exploiting the comment in LavaMoat.

This is the only reason to consider the browserify trick at runtime. It depends on eval though and is therefore unusable for us. Unless we have a non-eval alternative the work I put into typing all this up is for nothing anyway ;)

[kriskowal]

Have we censored the functorSrc at this point?

[kumavis]

we had not censored -- this has been fixed by running the "mandatory transforms"

[kriskowal]

Partial review for today.

[kriskowal]

Ocap violation. The relevant powers of these modules must continue to be threaded through the powers argument. (Are these referenced?)

[kumavis]

relevant comment

endo/packages/compartment-mapper/src/bundle.js

Lines 416 to 419 in 16d0c2f

	// these read powers must refer to the disk as we are bundling the runtime from
	// this package's sources. The user-provided read powers used elsewhere refer
	// to the user's application source code.
	const { read } = makeReadPowers({ fs, url });

unsure how to proceed - ask the bundle for two different read powers?

[kriskowal]

Probably. What are the two file systems in this case?

[kumavis]

1. this repo's file system so we can bundle the secure bundler runtime
2. the user's file system for their app

[kriskowal]

Have we censored the functorSrc at this point?