A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?
On a brief look, I agree that your link [1] does not appear to be thinking about capabilities correctly. It seems to make the classic mistake of orienting around verbs (actions you can do) instead of nouns (specific resources you can operate on). That said I only took a brief look and could be misunderstanding something.
However, my understanding is that WASI itself is actually capability-based, and I think your link [0] is thinking about capabilities in the right way. In fact I'm pleased to see "Interposition" seems to have been added here, IIRC a few years ago that was missing and I feel it's an essential piece of capability-based security.
As an example, in WASI, there is no singleton filesystem, instead the application receives a set of file descriptors for specific directories which grant access only to those directories and their children, not their parents. Though last I looked, the libc wanted to reconstruct those into a single virtual filesystem, assigning each one a mount point and matching paths against those, in the name of compatibility, which felt unfortunate to me.
As always, a lot of people struggle to "get" capabilities, even when they are building on top of a platform designed around the idea. :/
Well, I think it is a different approach. But in another submission I posted, "WebAssembly for the Server Side: A New Way to Nginx" [0], sponsored by Nginx, they mention things feeding the confusion again:
> Perhaps most importantly, role-based access control and attribute-based access control, and other authorization and access control technologies, can introduce complex external systems that must be synchronized with the plugin as well as the underlying server-side technology. In contrast, Wasm access control capabilities are often built directly into the runtime engines, reducing the complexities and simplifying the development process.
A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?
[0] https://github.com/WebAssembly/WASI#capability-based-securit...
[1] https://cosmonic.com/docs/category/capabilities
[2] https://en.wikipedia.org/wiki/E_(programming_language)
[3] https://capnproto.org
[4] https://github.com/ocapn/ocapn