LXC & Docker Security in 2014: Don't Let Your Container Break Out

Let’s be honest: the hype around Docker 1.0 has been deafening since June. Developers are pushing containers to production because "it works on my machine," but us sysadmins are the ones waking up at 3 AM when a kernel panic takes down the entire node. The promise of sub-second deployment is seductive, but the security model of shared-kernel virtualization scares the hell out of anyone who remembers the early days of chroot jailbreaks.

Unlike a proper hypervisor, containers share the host's kernel. If a process inside your container manages to exploit a kernel vulnerability, it doesn't just crash the container—it owns the host. In a multi-tenant environment, that is a nightmare scenario.

The Root of the Problem (Literally)

The default behavior in most container setups right now—including Docker 1.2—is to run processes as root. Sure, it’s "root" inside a namespace, but if that isolation layer has a crack, you are effectively giving root access to the host system. We saw this recently with the shocker.c exploit which demonstrated just how easy it is to break out of a container if capabilities aren't dropped correctly.

When you deploy on CoolVDS, we mitigate this risk at the infrastructure level by enforcing KVM (Kernel-based Virtual Machine) virtualization. Your VPS has its own kernel. Even if your containerized app gets compromised, the attacker is trapped inside your Virtual Machine, not roaming free on our bare metal in Oslo. That’s the difference between a bad day and a lawsuit.

Hardening Your Container Host

If you are running LXC or Docker on your VPS, you need to strip down privileges. By default, containers keep way too many Linux capabilities.

1. Drop Capabilities

Do your web workers really need CAP_SYS_BOOT or CAP_NET_ADMIN? Absolutely not. When launching a Docker container, you must explicitly drop these. Here is how I run Nginx containers to ensure they can't mess with the network stack:

docker run -d --name web_worker \n  --cap-drop=ALL \n  --cap-add=NET_BIND_SERVICE \n  --cap-add=SETUID \n  --cap-add=SETGID \n  -p 80:80 nginx:1.6.1

This command drops all capabilities and adds back only the ones strictly necessary to bind port 80 and handle user switching. It’s paranoid, but paranoia pays the bills.

2. Network Segregation with iptables

By default, Docker bridges all containers to docker0, allowing them to talk to each other. If one container is breached, it can scan and attack its neighbors. We need to lock this down at the iptables level. On a standard CentOS 6 or Ubuntu 14.04 host, you should restrict inter-container communication.

Add these rules to your host's firewall script:

# Drop all forwarding between containers by default\niptables -I FORWARD -i docker0 -o docker0 -j DROP\n\n# Allow specific link (e.g., Web to DB)\n# Assuming Web is 172.17.0.2 and DB is 172.17.0.3\niptables -I FORWARD -i docker0 -o docker0 \n  -s 172.17.0.2 -d 172.17.0.3 -p tcp --dport 3306 -j ACCEPT

Pro Tip: Managing iptables manually for dynamic containers is painful. Look into configuration management tools like Ansible or SaltStack to automate rule generation when you deploy new containers. We use Ansible extensively at CoolVDS to manage our own infrastructure.

The AppArmor Safety Net

If you are on Ubuntu 14.04 LTS (which you should be, considering the kernel support), AppArmor is your last line of defense. Docker ships with a default profile, but it is often too permissive. You should verify that the profile is actually loaded and enforcing.

# Check AppArmor status\nsudo apparmor_status\n\n# Verify Docker profile is loaded\ncat /sys/kernel/security/apparmor/profiles | grep docker-default

If you are writing a custom profile, focus on denying write access to /proc and /sys. Here is a snippet for a custom profile /etc/apparmor.d/docker-nginx ensuring the container cannot write to critical system paths:

profile docker-nginx flags=(attach_disconnected,mediate_deleted) {\n  # access to network\n  network inet tcp,\n  network inet udp,\n  network inet icmp,\n\n  # deny writes to proc and sys\n  deny @{PROC}/** w,\n  deny @{sys}/** w,\n  \n  # allow read only\n  /var/log/nginx/* r,\n  ...\n}

Why "Bare Metal" Containers Are a Liability in 2014

There is a trend among budget hosting providers to sell "Container VPS" based on OpenVZ or Virtuozzo. They claim it's faster. What they don't tell you is that you are sharing a kernel with potentially hundreds of other customers. If Neighbor A crashes the kernel, You go down.

In Norway, where data integrity is governed by strict laws like the Personopplysningsloven, you cannot afford that risk. This is why CoolVDS uses KVM exclusively. We give you a slice of hardware-level virtualization. You can run Docker inside your CoolVDS instance (Nested Virtualization effectively) and gain the speed of containers for your app deployment, while retaining the iron-clad security boundary of a hypervisor.

Performance Check: Overhead?

You might ask: "Does running Docker inside KVM add latency?" We tested this against our NVMe storage backend in Oslo.

The performance penalty is negligible compared to the security gains. Your data stays in Norway, your kernel stays yours, and your uptime stays at 99.99%.

Final Thoughts

Containerization is the future of deployment, but in 2014, the tooling is still maturing. Don't trust the defaults. Drop capabilities, segregate networks, and for the love of Tux, do not run containers directly on shared hardware. Wrap them in a proper KVM VPS.

Ready to build a fortress? Spin up a KVM instance on CoolVDS today. Our Oslo datacenter is optimized for low latency and high security.