Mozilla, Fastly, Intel, and Red Hat have teamed up to develop technologies that make WebAssembly a universal platform for safely executing code on any infrastructure, operating system, and device. For the joint development of runtime and compilers, allowing WebAssembly to be used not only in web browsers, the Bytecode Alliance community has been formed.
To create portable programs delivered in WebAssembly format that can be run outside the browser, it is proposed to use the WASI API (WebAssembly System Interface), which provides program interfaces for direct interaction with the operating system (POSIX API for working with files, sockets, etc.). A distinctive feature of the execution model of applications using WASI is the launch in a sandbox environment to isolate from the main system and the use of a security mechanism based on capability management - for actions with each of the resources (files, directories, sockets, system calls, etc.) the application must be given the appropriate authority (only access to the declared functionality is provided).
One of the goals of the created alliance is to solve the problem of the spread of modern modular applications with a large number of dependencies. In such applications, each dependency can be a potential source of vulnerabilities or attacks. Obtaining dependency control allows you to gain control over all applications associated with it. Confidence in the application automatically implies the existence of trust in all dependencies, but dependencies are often developed and accompanied by extraneous teams whose activities cannot be controlled. Bytecode Alliance members intend to prepare a complete solution for the safe execution of WebAssembly applications that are not initially trustworthy.
For protection, it is proposed to use the concept of nanoprocesses, in which each dependency module is separated into a separately isolated WebAssembly module, whose authority is set to bind only to this module (for example, a library for processing strings cannot open a network socket or file). Unlike process separation, WebAssembly handlers are lightweight and require almost no additional resources - the interaction between the handlers is not much slower than calling ordinary functions. Separation can be made not only at the level of individual modules, but also at the level of groups of modules, which, for example, need to work with common areas of memory
Requested permissions can be defined both at the level of dependencies themselves and delegated to dependencies in a chain by parent modules (resources in WASI are associated with a special type of file descriptors - capability). For example, the module can be delegated the ability to access a specific directory and system calls, and if the development infrastructure of the module is compromised or a vulnerability is identified, access will be limited only by these resources. Declaring resources by the creators of modules can become an indicator of suspicious activity, for example, when a text processing module requests permission to open a network connection. Initially, the set permissions are checked, and if they change, the dependency load is rejected until the local module signature is updated.
For joint development, several projects related to WebAssembly, previously separately developed by the founding companies of the alliance, were transferred under the Bytecode Alliance wing:
- Wasmtime, a small and efficient runtime for WebAssembly & WASI
- Lucet, an ahead-of-time compiler and runti
- me for WebAssembly & WASI focused on low-latency, high-concurrency applications
- WebAssembly Micro Runtime (WAMR), an interpreter-based WebAssembly runtime for embedded devices
- Cranelift, a cross-platform code generator with a focus on security and performance, written in Rust