Filters also provide little help when a vulnerability is discovered in a system call that your application requires. In practice, it’s often difficult to know which system calls will be required by an application beforehand. Kernel features like seccomp filters can provide better isolation between the application and host kernel, but they require the user to create a predefined whitelist of system calls. Furthermore, even with these limits, the kernel still exposes a large surface area that malicious applications can attack directly. These limits are implemented through the use of Linux cgroups and namespaces, but not all resources can be controlled via these mechanisms. With traditional containers, the kernel imposes some limits on the resources the application can access. The kernel runs in a privileged mode that allows it to interact with the necessary hardware and return results to the application. Traditional Linux containers are not sandboxesĪpplications that run in traditional Linux containers access system resources in the same way that regular (non-containerized) applications do: by making system calls directly to the host kernel. gVisor integrates with Docker and Kubernetes, making it simple and easy to run sandboxed containers in production environments.

To that end, we’d like to introduce gVisor, a new kind of sandbox that helps provide secure isolation for containers, while being more lightweight than a virtual machine (VM). However, the system surface exposed to containers is broad enough that many security experts don't recommend them for running untrusted or potentially malicious applications.Ī growing desire to run more heterogenous and less trusted workloads has created a new interest in sandboxed containers-containers that help provide a secure isolation boundary between the host OS and the application running inside the container. Containers have revolutionized how we develop, package, and deploy applications.

Sandboxie open source