wasmCloud / wascc-host

Library for hosting actors and capability providers in a host process
Apache License 2.0
201 stars 15 forks source link

Security of hosting foreign actors #70

Closed TheNeikos closed 4 years ago

TheNeikos commented 4 years ago

I did not find anything specific on the security of foreign actors running on a wascc-host. The docs do mention that each actor should be isolated etc... but nothing on the actual existing security measures. So I am wondering if this is a possible goal of the project (be it indirect or direct).

I also have not found much info regarding the WASI configuration/usage. What kind of access do actors have per default?

autodidaddict commented 4 years ago

There is no distinction between foreign and non-foreign actors in waSCC. All actors are isolated from each other. They cannot share memory, they do not share bindings to capability providers either locally or when distributed across a lattice. Actors do not and will never have access to WASI functionality. Actors are intended to be pure feature/business logic, and any capability they need will come from a capability provider. Capability providers can actually be WASI modules, but actors are designed to be completely isolated from the OS, root file system, and everything else save for their list of bound capabilities. When loading actors, we do not satisfy the WASI imports, so an actor with WASI requirements will fail to load during the JIT compilation process. To put a finer point on it, actors are also required to be 100% pure and compliant with the base unaltered WebAssembly spec for maximum compatibility and portability, which precludes the use of WASI.

If you want to limit which actors can invoke which other actors, then you can supply your own implementation of the Authorizer trait to the WasccHost when you create it. This trait also contains a hook that you can use in order to reject an actor from even being loaded (for example, you may not trust that actor's issuer).

The standard security measures enforce complete isolation between actors though actors can, by default, call each other (which you can then limit/control with your own custom authorizer). Actors do not share data, and capability providers bound to multiple actors will not share data between those actors.

Further, we also enforce that an actor's bytes have not been tampered with since it was signed.

If you send me your e-mail I will send you an invite to the WebAssembly in the Cloud slack which has waSCC channels. Let me know if this didn't answer your question or you're thinking that you need more security constraints we don't support.