Endo: thread powers by policy

[kriskowal]

Endo currently creates compartment graphs where all third-party packages are completely powerless. They do not receive any powerful built-in modules and do not receive any global or lexical “endowments”. The intention is for the run-time to thread built-in modules and globals or lexicals as described in the “compartment map”. Endo’s module loader would need to generate these threads based on the policies generated by LavaMoat. LavaMoat would in turn use Endo’s loader API to generate policies based on static analysis of the loaded module working set. LavaMoat would in turn collect suggestions from third-party package.json (e.g., this library is designed to run with a frozen global and defends its own API objects so advises you not to create unnecessary membranes) and overrides from the application package.json (e.g., use this package in place of that package).

To do this, we need an ESM LavaMoatStaticRecord constructor and will use the existing policy aggregator in LavaMoat core.

[kriskowal]

cc @erights @kumavis

[kriskowal]

I’ve since change Endo such that every package receives all of the endowed globals and modules. This gives us parity with our existing Rollup solution. This issue tracks support for least-authority linkage.

[kriskowal]

Passing this to @naugtur to sign off if it’s done done.

[kumavis]

cc @boneskull -- i believe this is the top-level "endomoat" ticket for this repo

[boneskull]

@kumavis I seem to have misplaced my context. What is this?

[kumavis]

@boneskull

🤠 this here is the endomoatiest ticket this side of the endo-lavamoat divide 🌵

This ticket is for tracking policy support in Endo. At present, the exact criteria for closing this ticket can only be viewed in a dream state. If you awake from this dream and find the criteria has been met, please close this ticket.

[boneskull]

Ref:

• feat: create @lavamoat/node LavaMoat/LavaMoat#772