An In-Depth Look at Sandbox Technologies

An In-Depth Look at Sandbox Technologies

Virtual machines (VMs), containers, and WebAssembly (WASM) sandboxes all essentially utilize sandbox technologies to isolate untrusted programs and execute them within secure environments. This prevents any potential impacts on other applications and services.

There are broadly two types of sandbox technologies:

  • Isolation-based sandboxes: This type of sandboxing creates an independent environment that isolates an application's execution from the underlying operating system (OS) environment.

  • Policy-based sandboxes: This type of sandboxing does not focus solely on isolating applications, but also controls the permissions of each application through policies. Policy-based sandboxes can share logical resources of the OS.


Comparison and Analysis of Sandbox Security Isolation Capabilities

1.??? VMs:

The security isolation capability of VMs can be simply summarized as multidimensional isolation in both horizontal and vertical directions. In the horizontal direction, the VM Hypervisor separates different guest OSs to ensure that vulnerabilities in one guest OS do not affect other guest OSs. In the vertical direction, the Hypervisor separates different OSs (guest OSs and host OSs do not share kernels) and physical hardware, so that vulnerabilities in guest OSs do not affect host OSs and physical hardware.

2.??? Containers:

The security isolation capability of containers also draws on the idea of VM-based isolation, which runs different applications in separate container environments horizontally. This ensures that any vulnerabilities in an application in a container do not have direct impacts on other applications.

However, in the vertical direction, containers share a common kernel, which results in incomplete isolation. This means that if one container experiences a kernel vulnerability that leads to a kernel crash, applications in other containers across the entire system will also be affected.

3.??? WASM sandboxes:

WASM utilizes software fault isolation (SFI) in its language design (i.e. the isolation-based sandbox technology), which confines all faults of WASM applications within separate linear address spaces. This ensures that the applications do not jump to address spaces outside of the fault domain, thus achieving the goal of secure isolation. In addition, the virtual instruction sets of WASM are pure computing instruction sets, which do not involve access to the kernel or hardware resources like VMs or containers.

The WebAssembly system interface (WASI)?is designed based on the policy-based sandbox technology or a capability-based security model. It controls the permissions of each WASM application in a policy-based manner. Each application needs to be explicitly configured with corresponding policies for the capabilities it requires.

The WASM+WASI sandbox technology offers a lightweight and efficient sandbox solution by combining the advantages of both the isolation-based and policy-based sandbox technologies.


Integration of WASM Sandboxes to Cloud Native Ecosystems

WASM sandboxes can achieve millisecond-level cold startup while ensuring secure isolation. If they are integrated into a cloud native ecosystem, the primary focus should be on leveraging the ultra-fast startup capability for optimal performance.

Kuasar has redefined the traditional concept of sandboxing by dissociating it from the containerd-shim process model and instead directly associating it with specific objects, such as lightweight MicroVM sandboxes and language VM-based WASM sandboxes, through its API design.

Currently, Kuasar supports two mainstream WASM runtimes in the industry: Wasmtime and WasmEdge.

1.??? Solution for Connecting Kuasar to Wasmtime

The architecture for connecting Kuasar to Wasmtime runtime is based on a coroutine model. The sandbox management module wasm-sandboxer and the container management module wasm-task both run in the same process. The WASM sandbox instances created by wasm-task also run in the wasm-sandboxer process.?This design offers the benefit of fully leveraging the coroutine scheduling mechanism within a single process to reduce the scheduling overhead of WASM sandbox instances, avoids the consumption of system PID resources, and increases the deployment density on a single node.

1.??? Solution for Connecting Kuasar to WasmEdge

The architecture for connecting Kuasar to WasmEdge runtime differs slightly from that for connecting to Wasmtime runtime. When a request is received by wasm-task to create a WASM sandbox, it creates a new process through a fork system call to instantiate the sandbox. This design is necessary because the current version of the WasmEdge runtime does not support redirection of standard inputs and outputs for multiple WASM sandboxes within the same process.

For more information about sandbox technologies, please visit the openEuler official website.

要查看或添加评论,请登录

openEuler的更多文章