There has been some promising prior research such as BreakApp attempting to mitigate unusual supply-chain compromises such as denial-of-service attacks targeting the CPU via pathological regexps or other logic-bomb-flavored payloads.
There's a great paper implementing this idea in the node.js ecosystem; [BreakApp: Automated, Flexible Application Compartmentalization](https://ic.ese.upenn.edu/pdf/breakapp_ndss2018.pdf) which modifies the `require` signature to allow specifying a security scope in which the module can be run.
It doesn't quite work at the capabilities level, but it does provide some novel protections against unusual supply-chain attacks such as denial-of-service attacks which may otherwise require no special capabilities.
This is similar to my work on LavaMoat (https://lavamoat.github.io/) which provides runtime supplychain security protections to js apps (nodejs or browser) by eliminating ambient authority and only exposing global capabilities per npm package according user-specified policy. LavaMoat is used in production at MetaMask, protecting ~300M users.
Thanks for the BreakApp paper. I read it this morning. This sort of thing is heading in the right direction and I've explored it before (without writing a paper), but there are some problems with their approach that they seem to have ignored which ended up sucking up a lot of the time I put into it. OTOH there are lots of good points: the usability issues are front and center, and they (very roughly) sketch out a threat model.
The first problem is that their attempt to abstract program location has a lot of bugs. You can't solve cross-process GC with the approach they outline (in like, one paragraph). Using finalizers to release cross-process references fails the moment there's a reference cycle. To trace cycles across heaps requires a new kind of GC that doesn't exist today, as far as I know, made much harder by the fact that they're including DoS attacks in their threat model. And intercepting value writes then batching them to save IPCs changes program semantics in pretty subtle ways. I think this is actually the core problem of sandboxing libraries and everything else is a well understood implementation distraction, so it'd be good to have a paper that focused exclusively on that. They also seem to think that modules return DAGs but they don't, program heaps are directed cyclic graphs, not acyclic.
The second problem is that their policy language is too simple and doesn't have any notion of transitive permissions. This is the same issue that made SecurityManager hard to use. You can grant a module filesystem access but in a typical JS app being tested or run on a developer's desktop, that's equivalent to granting all permissions (because it can write to some module directory). Even if you use Docker to ship the app there's no guarantee the js files inside the container are read only, as in a container programs often run as root.
The third problem is the only sandbox they offer is LXC containers, but containers aren't meant to be sandboxes and often aren't "out of the box". And of course they're Linux specific but development of JS apps often takes place on non-Linux machines. The details of actually doing kernel sandboxing for real are rather complex.
Still, something like this is the right direction of travel. The usability issues with process sandboxing arise due to performance problems and the harshness of the address space transition. Allowing object graphs to be 'shadowed' into another process, with proper handling of memory management, and then integrating that into language runtimes seems like the right approach.
I've implemented parts of DCOM! (for Wine). What it calls distributed GC isn't really. It's just about releasing refs held by clients that have gone away. You can still have reference cycles that are never collected in DCOM.
One of the reasons I added this support was so we could use the parser on our client-side handlebars templates to identify glyph usages and build the smallest possible custom fonts.
There has been some promising prior research such as BreakApp attempting to mitigate unusual supply-chain compromises such as denial-of-service attacks targeting the CPU via pathological regexps or other logic-bomb-flavored payloads.