# Getting Towards Real Sandbox Containers

DevFeed: [Getting Towards Real Sandbox Containers](<https://devfeed.tech/articles/getting-towards-real-sandbox-containers-35166.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/>)

Published: 2016-05-01T19:17:58Z

Content type: article

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [Containers](<https://devfeed.tech/topics/containers.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>)

Tags: [cgroups](<https://devfeed.tech/tags/cgroups.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [containers](<https://devfeed.tech/tags/containers.md>), [docker](<https://devfeed.tech/tags/docker.md>), [linux](<https://devfeed.tech/tags/linux.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>), [selinux](<https://devfeed.tech/tags/selinux.md>)

## AI overview

The article examines whether containers can provide application-sandboxing properties comparable to the Chrome sandbox. It explains that containers use Linux features such as user namespaces, seccomp, and cgroups, but highlights privilege and unprivileged cgroup-creation challenges, especially when containers run as root.

## Source excerpt

Containers are all the rage right now. At the very core of containers are the same Linux primitives that are also used to create application sandboxes. The most common sandbox you may be familiar with is the Chrome sandbox. You can read in detail about the Chrome sandbox here: chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md. The relevant aspect for this article is the fact it uses user namespaces and seccomp. Other deprecated features include AppArmor and SELinux. Sound familiar? That's because containers, as you've come to know them today, share the same features. Why are containers not currently being considered a "sandbox"? One of the key differences between how you run Chrome and how you run a container are the privileges used. Chrome runs as your own unprivileged user. Most containers (be it docker, runc, or rkt) run as root. Yes, we all know that containers run unprivileged processes; but creating and running the containers themselves requires root privileges at some point. How can we run containers as an unprivileged user? Easy! With user namespaces, you might say. But it's not exactly that simple. One of the main differences between the Chrome sandbox and containers is cgroups. Cgroups control what a process can use. Whereas namespaces control what a process can see. Containers have cgroup resource management built in. Creating cgroups from an unprivileged user is a bit difficult, especially device control groups. If we ignore, for the time being, this huge tire fire that is creating cgroups as an unprivileged user, then unprivileged containers are easy. User namespaces allow us to create all the namespaces without any further privileges. The one key caveat being that the {uid,gid}_map must have the current host user mapped to the container uid that the process will be run as. The size of the {uid,gid}_map can also only be 1. For example if you are running as uid 1000 to spawn the container, your {uid,gid}_map for the process would b