A programmable sandboxing tool, Styrolite locks down Linux kernel namespaces to provide lightweight sandboxes for container-based workloads.
Today Edera launched a new open-source project called Styrolite to bring tighter controls to the interactions between containers and Linux kernel namespaces, at a layer below where Open Container Initiative (OCI) runtimes like containerd operate.
While software supply chain security incidents like Log4j and XZ Utils have dominated the container security headlines in recent years, the container runtime remains an irresistible target. Exploits that target low-level kernel subsystems, such as Dirty Cow and Dirty Pipe, allow attackers to escape containers and escalate privileges.
Created by Ariadne Conill, co-founder and distinguished engineer at Edera, Styrolite is a programmable sandboxing tool that gives platform engineering teams the ability to “quarantine” the interactions between containers and Linux namespaces. The name comes from a sci-fi quarantine substance in Star Trek Next Generation.
Historically, the container runtime has provided very poor isolation guarantees, Conill says. “I think we’ve gotten to a point where people just don’t understand how these components come together, and think that namespaces provide true isolation,” she said. “They can’t, because they exist as a subset of the shared kernel state.”
Slippery Linux namespaces
Linux namespaces allow containers to contend for underlying resources in multi-tenant environments. But while the container-to-Kubernetes handshake requires the flexibility to place workloads side-by-side on various Linux hosts across clusters, Linux namespaces were never intended to serve as security boundaries. Which is why container runtime attacks and container escapes are so prevalent.
“Essentially Styrolite is similar to a container runtime interface (CRI) but focused on the containers’ actual interactions with the kernel,” Conill says. “Styrolite focuses on securing the fundamentals of how images get mounted into namespaces in areas like timekeeping, mounts, and process collections in the process ID namespace.”
By managing the life cycle for those core namespace interactions, Styrolite gives engineers much more granular control over the resource interactions of containers, through configuration of their container images.
Written in Rust and designed as a microservice, Conill says Styrolite helps “bridge the gap between the modern cloud-native computing paradigm and traditional security techniques like virtualization-based security.”
“We’ve basically made Styrolite behave in a similar way to how OCI components work,” said Conill. “In essence, we’ve turned the container sandbox management into a proper microservice in the same way that Kubernetes uses the CRI to connect to containerd or other CRI implementations.”
Sandboxing container runtimes
There have been other attempts at sandboxing container runtimes. Bubblewrap is the best known, as the low- level container sandboxing project commonly used for Fedora and RPM builds.
“These tools are either too high-level (like the Kubernetes CRI), or they are designed to be used via shell scripting,” said Conill. “While CLIs allow for rapid iteration, we wanted to build a rich programmatic interface for spawning and managing containers.”
For developers and security professionals used to Bubblewrap, Conill says they will immediately notice how differently Styrolite handles security configurations. Bubblewrap is a very opinionated tool with a complex command line interface that makes it easy for someone moving too fast to inadvertently escalate privileges to hosts, she says.
“Navigating these runtime configurations without proper guardrails is how you can accidentally grant containers full root directory access on a host, when you were merely trying to pass through file sharing,” Conill said.
Conill sees a broad security awakening underway in container security, and she believes tools like Styrolite are foundational to better security configurability by default.
