object capability demonstration using secure VATs

[amiller]

There's a great body of work on object capability languages as a way of managing the risk of running untrusted code modules by only exposing limited fine-grained capabilities to the untrusted code.

http://www.erights.org/

But, while the subject is untrusted code, the environment itself in which the code runs, called a "Vat", must be considered trusted.

This is problematic when using cross-vat distributed code, because one malicious vat can steal the "Swiss number" references (random unguessable strings, effectively symmetric keys).

This makes it hard to reconcile object capability languages with smart contracts. In smart contracts we go out of our way to run consensus protocols so that a trusted environment can be built on untrusted nodes, but we can't assume privacy and so we can't use Swiss number references.

So now, by instantiating the vat with Dstack, we might be able to close this gap and draw some more insights or better composition / better hardening as a result.

As a starting point, we might simply run existing ocap sandbox in Dstack, possibly adding a new shim for referencing objects in different Dstack instances as different vats
https://github.com/endojs/endo

A more thoughtful example probably needs to illustrate some pattern of passing serialized/hardened code, containing Swiss numbers or even private keys, between such sandboxes. Needs more thought though

chatgpt discussion:
https://chatgpt.com/share/67ff0b25-b580-8009-a13b-d5ca70cb5fb7

[h4x3rotab]

Looks very interesting. I'd like to learn more about your and their motivation. Does it aim to solve the trust problems in composable software (contracts)? One example in my mind is running proprietary code in a sandbox environment together with a TEE framework.

[amiller]

Yeah that's exactly the idea. It's about mitigating the trust required in composable software. Usually there's still some expectation that the untrusted code has some desired behavior, and it could be that the code is buggy so it doesn't do what it's supposed to. But, by limiting the capability/authority granted to the untrusted code, we can at least prevent it from doing more damage than it has to.

This capability language is basically a way of packaging up fine-grained authority to give to a program. Basically you can hand the untrusted code a function pointer, it can call the function but can't pick apart the function.

A good example is a function that creates a log entry every time its used - the point of the sandbox is to make sure the logging step can't be bypassed. Another good example is a function pointer that includes a usage counter or rate limit. The sandbox would then ensure that the untrusted code can't bypass the counter restriction.