SES (or Jessie) today (June 2021)? A case study

Hi crew, I’m seeing a lot of progress on the Agoric repositories in the recent days, and the security blockers list is looking really good, kudos all around!

For the umpteenth time in the last few decades, I’m looking to start an ocap-based, green-field Rapid Application Development (RAD) hosted thingie. (This time around, my excuse to my boss is to create a multi-tenant fill-a-form-and-seek-approval workflow platform. With BPMN and all that, yayy.)

Basically I’m envisioning a “low-code” platform in which customers provide workflows as data in suitable format (BPMN, serialized Form.io forms, ACLs as LDAP expressions etc) plus the inevitable fine-tuned customization as JS code, which should run sandboxed either server-side (e.g. in which direction should the next workflow step go) and/or client-side (e.g. form validation).

I do not need any of

  • determinism / blockchain consensus / input bit confinement
  • sub-sandboxes / multiple vats (the API design will keep the attack model single-tenant; see below)
  • … in fact, any kind of banking-grade security; making attacks tamper-evident is good enough as of Version 1 (I’ll be staging customer code into a local git clone that I never gc)
  • tamed DOM or in fact, any tamed legacy API (browser or otherwise). I intend to provide the customer scripts with a home-made and hand-tamed API, and it will be domain-specific instead of general-purpose (e.g., a customer will not wield enough authority to fashion a custom form widget, except indirectly through pull request to the core system).

As I am reading things today, it looks like my job could be as simple as

  1. use node.js on the server side (I have my eyes on Meteor.js);
  2. load customer code as-is (no transpiling etc.) using SES du jour (perhaps inside a VM or off-domain iframe for double hulling / blast radius control);
  3. and merrily call it whenever I need the user code’s opinion on things (obviously taking due care to pass only harden()ed copies of the data, and heeding other applicable security advice).

Could someone please spare the time to explain to me whether / why this is a terrible idea?

1 Like

I’m clearly not here to provide a non-existence proof of arguments against doing this, but I can point you toward endo/packages/compartment-mapper that would allow your client code to be written as JS modules (with support for both ESM and CommonJS, on an ESM runtime). Your carve-out for non-goals is consistent with the non-goals of Endo. We’re building a platform based on SES to sandbox Node.js-style packages + CapTP.

Thanks @kris for the summary and pointers! I’ll keep the thread informed as (if) I make progress.