LXC & OpenVZ Security: Locking Down The Shared Kernel Nightmare

Everyone in the hosting world is currently screaming about "lightweight virtualization." We see it everywhere. Developers are pushing for LXC (Linux Containers) because it spins up in milliseconds. Hosting providers—especially the budget ones—love OpenVZ because they can cram 500 customers onto a single physical box and call it "cloud."

But let's be brutally honest: Most container deployments right now are a security disaster waiting to happen.

I have spent the last week auditing a client's infrastructure in Oslo. They were running sensitive customer data inside standard LXC containers on Ubuntu 12.04. They thought they were secure. They weren't. A kernel exploit in one container could have given an attacker root access to the host node—and consequently, every other customer's data. In the eyes of Datatilsynet (The Norwegian Data Protection Authority), that is not just a breach; it is negligence.

If you are running LXC or OpenVZ, you are sharing a kernel. If you are sharing a kernel, you are sharing risk. Here is how to mitigate that risk, and why we at CoolVDS often recommend KVM instead.

The Root Problem: Shared Kernels

In a hardware virtualized environment (like KVM or Xen), the guest OS has its own kernel. If the guest kernel panics or gets owned, the hypervisor remains isolated. In container virtualization (LXC/OpenVZ), the "guest" is just a set of processes on the host's kernel, segregated by namespaces and cgroups.

The problem? As of today, February 2013, the implementation of user namespaces in the mainline Linux kernel is still experimental (expected in 3.8, but not stable yet). This means root inside your container is effectively root on the host, just with a few blinders on.

Defense Strategy 1: Drop Capabilities

If you must use LXC, you strictly limit what the container's root user can do. By default, LXC allows too much. We need to drop capabilities like CAP_SYS_MODULE (loading kernel modules) and CAP_SYS_ADMIN (a catch-all for administration).

Edit your container configuration file, typically located at /var/lib/lxc/CONTAINER_NAME/config, and append these drop instructions:

# Drop dangerous capabilities
lxc.cap.drop = sys_module
lxc.cap.drop = sys_nice
lxc.cap.drop = sys_pacct
lxc.cap.drop = sys_rawio
lxc.cap.drop = sys_time
lxc.cap.drop = audit_write
lxc.cap.drop = audit_control

This prevents a compromised container from inserting a kernel module to hide a rootkit or changing the system clock, which can wreak havoc on log timestamps and audit trails.

Defense Strategy 2: AppArmor Profiles

On Ubuntu systems, AppArmor is your second line of defense. It acts as a mandatory access control (MAC) system that wraps around the container. If the container tries to write to /proc/sysrq-trigger or mount a filesystem it shouldn't, AppArmor blocks it, even if the user is root.

Ensure your LXC config includes the AppArmor profile. The default lxc-container-default is a good start, but for high-security environments, you should clone and tighten it.

# /var/lib/lxc/CONTAINER_NAME/config
lxc.aa_profile = lxc-container-default

To verify AppArmor is actually enforcing rules, check the status on the host:

sudo apparmor_status

You should see profiles in "enforce" mode, not "complain" mode. Complain mode only logs violations; it doesn't stop them.

Defense Strategy 3: Network Isolation

By default, many simple container setups bridge the container directly to the host's network interface. While convenient, it exposes the container to ARP spoofing attacks against other containers on the same bridge.

At CoolVDS, we use strict iptables filtering on the host node to ensure traffic goes exactly where it's supposed to. A basic bridge setup in /etc/network/interfaces on the host is not enough. You need ebtables (Ethernet Bridge Tables) to prevent MAC spoofing.

# Prevent a container from spoofing MAC addresses
ebtables -A FORWARD -i veth+ -s ! 00:16:3e:xx:xx:xx -j DROP

# Prevent IP spoofing (ensure the container only sends traffic from its assigned IP)
iptables -A FORWARD -m physdev --physdev-in veth+ -s ! 192.168.1.50 -j DROP

Pro Tip: Never rely solely on the virtualization software's default network scripts. They are designed for connectivity, not security. Always layer your own netfilter rules on top.

The "Noisy Neighbor" Issue: cgroups

Security isn't just about hackers; it's about availability. In a shared kernel environment like OpenVZ, one user running a fork bomb or a heavy database query can starve the CPU for everyone else. This is the definition of a "noisy neighbor."

We use Control Groups (cgroups) to strictly limit resource usage. Never deploy a container without defining memory and CPU limits.

Here is an example configuration to limit a container to 512MB of RAM and 20% of CPU shares:

# Resource Limits
lxc.cgroup.memory.limit_in_bytes = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
lxc.cgroup.cpu.shares = 204

The Ultimate Solution: KVM (Why We Choose It)

While the strategies above make LXC/OpenVZ safer, they do not make it safe. The kernel surface area is simply too large. One zero-day exploit in the Linux kernel TCP stack, and the isolation is gone.

This is why CoolVDS is built primarily on KVM (Kernel-based Virtual Machine). With KVM, you aren't just getting a namespace; you are getting a virtualized CPU and your own independent kernel.

Comparison: OpenVZ vs. KVM

For a developer working on a non-critical internal tool, LXC is fantastic. But for a business in Norway handling customer data under strict compliance requirements, relying on software-level isolation is a gamble I am not willing to take.

Conclusion

If you are managing your own servers and deciding between virtualization technologies in 2013, remember this: Convenience is the enemy of security.

LXC allows you to spin up instances fast, but it requires deep knowledge of cgroups, AppArmor, and capability dropping to be even remotely secure. KVM gives you that security by default through hardware-assisted isolation.

At CoolVDS, we prioritize your data's integrity over density. We don't overstuff servers with hundreds of containers sharing a single kernel. We give you raw KVM power with low-latency NVMe storage (a rare find these days!) connected directly to the NIX in Oslo.

Don't let a shared kernel be your single point of failure. Deploy a true KVM VPS on CoolVDS today and sleep better knowing your root user is actually yours.