Quickest way to add sandboxing to current charm framework

[seefeldb]

This just a possible approach, but let's spell it out:

As background: (See common-runner/src/cell.ts)

• At a lower layer, data is organized in cells, of type CellImpl. They store raw values, which include aliases and references to other cells.
• When calling modules (i.e. lifted functions and event handlers), we send a CellProxy to them, which wraps the data in cells as a regular JS object, and – crucially – also resolves aliases and references under the hood. To the module it looks like a JS object that can even be a graph.
• The proxy is also writeable, and setting properties writes into the right underlying cell. Roughly the logic is that aliases are followed before writing but cell references are overwritten by new references (when assigning e.g. an object to a property). The proxy also wraps all array methods like push and handles those correctly.
• The single parameter to the lifted function (and the wrapper around handlers, that then calls the handler with two parameters) is actually also a single cell, but it only has either aliases or static data. This is called the inputs cell.

Proposal:

• Move the proxy entirely into the sandbox
• Bridge at the cell level, implementing the subset of CellImpl that the proxy uses (which I think is just getAtPath and setAtPath).
• There's a special id to request the corresponding input cell.
• And we could create a special id for a return value cell that we can write into. The main advantage there is that we then don't have to special case cell references in a serialized format.
• At first just proxy in the cell ids, later we make those opaque
• On the runtime side, the calls just directly map to the corresponding calls on the cell.
• Inside the proxy, let's collect the log as usual and then before returning have another call that sends that back.

So really just three exposes functions:

• getAtPath(cellId: string, path: PropertyKey[])
• getAtPath(cellId: string, path: PropertyKey[], value: any)
• reactivityLog({ reads: [cellId: string, path: PropertyKey[]][], writes: [cellId: string, path: PropertyKey[]][])

I think that's it, actually!

Bonus:

• We can exposes the builder proxy (which is different, I should rename it) as well, and teach it how to serialize it / deserialize it. Then we can reuse this for recipe creation as well (and it's also a requirement for some of the handlers we now use).

[jsantell]

After discussing, it sounds like a single host callback can be sufficient in supporting features in the lookslike prototype with minimal changes to the sandbox. Sandboxed code can execute the host callback via globalThis.hostCallback(..), args serialized into the host environment where the callback is executed, where the return value is sent back into the sandboxed content.

// common-os, main thread
let engine = new CTEngine((input) => {
  switch (input.message) {
    case "getAtPath": return getAtPath(...input.args);
    case "setAtPath": return setAtPath(...input.args);
    case "reactivityLog": return reactivityLog(...input.args);
    default: return undefined;
  }
});
let sandbox = engine.define(`
  export const run = (input) => {
    input.foo = input.foo + 1;

    let value = globalThis.hostCallback({
      message: "getAtPath",
      args: [/* .. */],
    });

    return input;
  }
`);

let result = sandbox.run({ foo: 1 });
console.assert(result.foo === 2);

An open question is if we need any "scoping" of host callbacks per instance. For example, in the above case, any sandbox can request any values for setAtPath/getAtPath. We may want to tag each sandbox/instance with some T/UserData/identifier.

[seefeldb]

Ah yes, that would be great, especially a tag that doesn't roundtrip through the sandbox so it can't be tampered with. Could just be an id that is generated by the API that invokes the sandbox?