Securing Applications with Linux Containers

I’ve been working in Linux security since 1999 when I was creating Bastille Linux and leading the work to create the Center for Internet Security’s first Linux security standards guide. In those early days, chroot (or “change root”) jails were popular. The idea is that you’d jail a program to either break an exploit or to contain the attacker who compromised a program.

To learn more about Linux containers, including how you can use them to break exploits and contain attackers, watch my corresponding webinar, "Securing Applications with Linux Containers". watch now

In 2005, Linux took the next step in jailing programs with the development of the Linux container. While there have been a number of container runtimes, Docker popularized this in 2013. I’m a fan of Docker and its offshoot “runc” program, as they make it easy to get your feet wet with containers. I like to show people how easily they can break exploits with containers.

Here are a few of the things you can do to a program in a container:

• Drop root capabilities
• Replace the root user with one that doesn’t have root privileges outside the container
• Filter system calls available to the program with seccomp
• Massively reduce the operating system programs available to the attacker
• Apply an AppArmor or SELinux profile specific to the container

Let’s talk about root capability dropping. In Linux, there are really only two classes of user; “root,” which can access any file or resource at will, and then there’s every other user, which can access only resources that it owns or that are made available to every user. The root user has a number of privileged special powers, like:

• The ability to listen on a TCP or UDP port below 1024
• The ability to override file ownership
• The ability to impersonate other users

There’s a control on this, though. Root’s special powers have been enumerated, with decent granularity, as root “capabilities.” When you put a program in a container, you can specify which capabilities exist in the container. This is incredibly useful since many programs that run with root privilege do so only to listen on a port below 1024. So, if you were to start a program in a container with no root capabilities except for NET_BIND_SERVICE, and an attacker compromises the program, he won’t be able to use any of root’s special powers. Depending on how you set up file ownership, he might not be able to write to a single file in the filesystem, even though he’s got root!

To learn more about Linux containers, including how you can use them to break exploits and contain attackers, watch my corresponding webinar, "Securing Applications with Linux Containers".