Mozilla’s Lin Clark recently announced the creation of the Bytecode Alliance. The Bytecode Alliance is an industry partnership that aims to propose and implement standards to enable the growth of a secure-by-default WebAssembly ecosystem, inside and outside the browser. The Bytecode Alliance introduced nanoprocesses to provide isolation and safety when running third-party Wasm packages.
Mozilla, Fastly, Intel, and Red Hat have joined forces to found the Bytecode Alliance. The goal of the alliance is to further the vision of a modular WebAssembly ecosystem, which remedies the security issues linked to the current massive usage of third-party packages (such as malicious dependencies, or corrupted modules) to build applications. Clark quoted that an estimated 80% of the code base for an application comes from package registries like npm, Pypy, and crates.io. Such third-party packages speed up the creation of an application, but also potentially introduce security issues. Developers trusting third-party packages assign to those packages the same capabilities as the full application, capabilities which may be used by malicious packages for unexpected purposes. Clark warned:
As a community, we have a choice. The WebAssembly ecosystem could provide a solution here… at least, if we choose to design it in a way that’s secure by default. But if we don’t, WebAssembly could make the problem even worse.
As the WebAssembly ecosystem grows, we need to solve this problem. And it’s a problem that’s too big to solve alone. That’s where the Bytecode Alliance comes in.
With the nanoprocesses proposal, which only lets packages run in an isolated environment with pre-determined and limited capabilities, the Bytecode Alliance seeks to contain and render inoperative the security vulnerabilities stemming from malicious packages. Clark explained:
Together, we’re putting in solid, secure foundations that can make it safe to use untrusted code, no matter where you’re running it—whether on the cloud, natively on someone’s desktop, or even on a tiny IoT device.
With this, developers can be as productive as they are today, using open source in the same way, but without putting their users at risk.
Nanoprocesses build on the existing or proposed security-oriented features of WebAssembly (such as sandboxing or memory isolation) and WASI (a capability-based security model), by allowing a finer-grained control of access or functionality passed on to third-party packages.
WASI applications are provided with capabilities, instead of forgeable references (such as a file path) that identify a resource but do not specify which access rights are appropriate for that resource. Under the WASI model, code can for instance only access directories that are passed in to it. The runtime thus passes in the file descriptors that an application can use to the top-level code, and then file descriptors get propagated through the rest of the system on an as-needed basis.
Nanoprocesses go a step further by allowing a nanoprocess to pass its dependent nanoprocesses only a chosen subset of the capabilities it has received (from the runtime or its parent nanoprocess). Clark illustrated the mechanism in the announcement blog post as follows:
Interested readers can go to the announcement blog post for further details about WebAssembly nanoprocesses and their additional expected benefits.
The Bytecode Alliance is already cooperating on a series of existing projects, including WebAssembly runtimes (Wasmtime, Lucet, WebAssembly Micro Runtime), runtime components (Cranelift, WASI common) and language tooling (cargo-wasi, wat, wasmparser). It also leads the WASI standards effort. and the Rust to WebAssembly working group.
The Bytecode Alliance signaled its interest in welcoming new members and growing the alliance. Interested parties may email the alliance at hello@bytecodealliance.org.