Introduction
In today’s changing world of technology, where different applications and workloads need to coexist in shared environments, the importance of security and isolation has significantly increased. The difference between traditional container architectures and more secure, sandboxed solutions lies in the level of isolation and security boundaries they provide—while traditional containers share the host kernel, sandboxed solutions like unikernels, specialized kernels, or VM-based hypervisors offer stronger separation and reduced attack surfaces. It has become crucial to protect applications from interfering with each other and limit the actions that workloads can perform. To address this concern various techniques for container sandboxing and isolation have emerged. This article aims to explore some of these software solutions and projects, such as seccomp, AppArmor, SELinux, gVisor, Kata Containers, Firecracker and Unikernels. We will discuss the strengths and weaknesses associated with each of them.
Introduction to Container Sandboxing
Imagine you have two workloads that you want to keep separate from each other. This is where containerization and virtualization play a role. These technologies enable you to run applications in isolated environments that make it challenging for them to interfere with one another. Another approach for achieving isolation is through sandboxing which involves restricting an application’s access to resources and system calls.
When you run an application, within a container it is essentially placed within its sandbox. Linux containers provide isolated environments for application running, but containers share the host OS kernel and resources, which can introduce security risks if not properly managed. Each container contains an application so if an attacker compromises one container they may attempt to execute code beyond what the application was designed for. Sandboxing mechanisms serve the purpose of limiting the capabilities of this code thereby restricting the attackers ability to impact the system. Process ID (process id) is used to identify and isolate processes within containers, helping to enforce boundaries between containers and the host system.
Container Runtime Environment
The container runtime environment forms the backbone of sandboxed containers, delivering the secure and isolated foundation necessary for running untrusted code in today’s complex IT landscapes. By leveraging lightweight virtual machines, the container runtime environment creates a protective barrier between running containers and the host operating system, significantly reducing the attack surface exposed to physical hardware and other applications.
At its core, the container runtime virtualizes the operating system, allowing each container to operate within its own isolated environment. This strong isolation ensures that even if untrusted code is executed within a container, it cannot easily impact the host machine or compromise other running containers. This is especially critical for organizations that need to run untrusted applications or third-party code, as it provides a robust defense against potential security issues.
One of the key strengths of the container runtime environment is its high degree of configurability. Developers and IT teams can tailor the environment to their specific needs—configuring the network stack, user space, and OS kernel, as well as setting granular access controls and security policies. This flexibility allows teams to create secure environments that align with their compliance requirements and operational goals, whether they are deploying a single app or orchestrating complex, multi-container systems.
Efficiency is another hallmark of modern container runtimes. By utilizing lightweight virtual machines, these environments require fewer resources than traditional virtual machines, making them highly efficient for both development and production environments. This resource efficiency enables organizations to maximize hardware usage, reduce costs, and scale applications seamlessly. Additionally, the container runtime environment supports a variety of packaging formats, such as Docker Compose files, simplifying the process of deploying, configuring, and managing containerized applications across different environments.
Leading solutions like Kata Containers and gVisor exemplify the advancements in container runtime technology. Kata Containers, for instance, use a virtualized hardware layer to provide strong isolation, making them ideal for running untrusted code in sensitive or regulated environments. gVisor, on the other hand, operates with a user-space kernel, offering a flexible and efficient runtime that balances security with performance—perfect for production workloads that demand both speed and protection.
In summary, the container runtime environment is a critical enabler for secure, efficient, and flexible sandbox environments. By isolating containers from the host operating system and physical hardware, and by offering extensive configuration options, the container runtime empowers organizations to confidently run untrusted code, protect valuable resources, and streamline application deployment in any production environment.
Seccomp: Restricting System Calls
Seccomp, an abbreviation for ”computing mode,” is a mechanism within the Linux kernel that controls and limits the set of linux syscalls an application can make. When it was initially introduced in 2005, seccomp only allowed processes operating in this mode to execute a limited set of system calls. These included sigreturn (for returning from a handler), exit (for terminating the process), and read and write operations using file descriptors.
In 2012, seccomp bpf (Berkeley Packet Filters) was introduced, enabling control over system call restrictions. It utilizes profiles to determine which specific linux syscalls a process is permitted to make. Each process can have its seccomp profile, and these profiles can be configured to allow or block specific system calls. The profile evaluates both the system call opcode and its parameters to decide whether it should be allowed, resulting in either an error message, termination of the process, or invocation of a tracer. Seccomp offers advantages in containerization scenarios as it can block unnecessary system calls that containerized applications should not need access to. For example, it can prevent attempts to modify the clock time or manipulate kernel modules. Docker employs a default seccomp profile that blocks more than 40 kinds of system calls, thereby enhancing security for most containerized applications.
However, by default Kubernetes does not implement a seccomp profile. But don’t worry—you have the option to add profiles using annotations on PodSecurityPolicy objects. If you want to configure your seccomp profiles, there are ways to go about it. You can manually trace system calls using tools like strace, or utilize eBPF-based utilities such as falco2seccomp or Tracee. Additionally, some container security tools offered commercially can automatically generate custom seccomp profiles for you.
AppArmor: Application-Level Access Control
Let’s talk about AppArmor now. It’s a Linux security module (LSM) that provides application level access control. When you associate profiles with files you determine what actions those files are allowed to perform in terms of capabilities and file access permissions. AppArmor can also restrict actions performed by the root user or on the root directory, adding an extra layer of protection to the root filesystem and limiting root privileges within containers. AppArmor ensures that mandatory access controls set by administrators are enforced effectively. This means users won’t be able to modify or bypass these controls easily. While Linux file permissions are access controls where users can grant or deny file access AppArmors mandatory controls cannot be altered by users since they’re centrally administered.
To create AppArmor profiles, for containers there’s a tool called “bane” that you can use. Once the profile is created simply install it under the /etc/apparmor directory. Load it using the apparmor_parser. With Docker, Containerd, CRI O and Kubernetes all you need to do is add annotations to your container definitions in order to make use of AppArmor profiles.
SELinux: Enhanced Security Through Labelling
SELinux, also known as “Security Enhanced Linux ” is an LSM developed by Red Hat. It uses labels to define the permissions and interactions of processes, with files and other processes. Each process operates within an SELinux domain, which represents its context while files are labelled with types. SELinux policies can also be used to control access to sensitive data and ensure secure data handling within containerized environments, providing an additional layer of protection for data analysis, data processing, and data storage.
In addition to discretionary access controls (DAC) SELinux adds mandatory access controls to enhance security. This means that administrators can establish policies that dictate what actions a process from a domain can perform on files of a particular type. SELinux policies can be logged for review than strictly enforced, similar to AppArmors “complain” mode. To create SELinux profiles it is crucial to have an understanding of an application’s file access requirements, in normal and error scenarios. While some vendors offer built profiles there may be cases where custom profiles need to be created for specific applications.
gVisor: Combining Sandboxing and Virtualization
gVisor, developed by Google, offers an approach to container isolation. gVisor runs containerized applications by intercepting system calls in a sandboxed environment, using a specialized user-space kernel to enhance security and isolate applications from the host OS. It acts as a user space kernel by intercepting system calls similar to how a hypervisor handles system calls for machines. Consisting of the “Sentry” and “Gofer” components, gVisor aims to provide higher levels of security and isolation compared to standard containers. The Sentry intercepts system calls made by the application and applies security measures using seccomp. It then delegates file-related system calls to the Gofer process. Within the Sentry itself, gVisor acts as a guest kernel in user space, reimplementing system calls.
While gVisor provides isolation, it does have limitations as not all Linux system calls are supported. This may restrict its usability for some applications. Additionally, applications with high rates of system calls might experience some performance impact, and gVisor’s approach can lead to increased memory usage for certain workloads.
For example, you can run a Python application securely within a gVisor sandbox to isolate its execution and manage system resources effectively.
Kata Containers: Running Containers in VMs
Kata Containers offers an approach by running containers within virtual machines, using the kata runtime to provide secure, high-performance container environments. This combines the advantages of utilizing container images with the enhanced isolation provided by virtual machines. To achieve this, Kata Containers utilizes a runtime proxy that leverages QEMU to create virtual machines for each container. In Kubernetes environments, Kata Containers can run on separate nodes to further enhance isolation between workloads. While this approach ensures strong isolation, it is important to note that running containers in VMs may require more resources and can result in longer startup times due to the virtual machine boot up process.
Firecracker: Lightweight Virtual Machines
Firecracker tackles the challenge of machine startup times by providing lightweight alternatives. With durations as low as 100ms, Firecracker is particularly suitable for container workloads that require advanced security through virtualization. Firecracker achieves fast startups by eliminating unnecessary functionality from the virtual machine image and minimizing the number of emulated devices, such as virtio-block, virtio-net, serial console, and keyboard controller. This limited set of devices reduces the attack surface and enhances security while maintaining resource efficiency. Firecracker operates within user space and utilizes KVM-based hardware virtualization. It is an open-source project developed to provide secure and efficient virtualization for container workloads.
Unikernels: Minimalistic Operating Systems
Unikernels take isolation to the extreme by creating machine images that only contain the components for running the application. This approach ensures attack surfaces and quick startup times.
To use Unikernels each application needs to be compiled into a Unikernel image, which includes all its required elements. While Unikernels provide security it does require applications to follow an Unikernel format.
Do you like to read more educational content? Read our blogs at Cloudastra Technologies, learn more about Cloudastra Technologies, or contact us for business enquiry at Cloudastra Contact Us.
To connect with other professionals, join our Discord community for support, sharing, and collaboration on container sandbox solutions.