Docker/LXC Root User Security Risks

TL;DR

A root user inside a Docker container or LXC virtual machine can potentially break the security of your host system, but it’s not automatic. It depends on how those containers/VMs are configured and what privileges they have access to. Proper isolation is key.

Understanding the Risks

Docker and LXC provide isolation, but it’s not perfect. Think of them as separate rooms in a house – you want strong doors (isolation) between the rooms, but if someone gets enough tools or finds weaknesses, they might be able to get out.

Steps to Mitigate Risks

1. Use Least Privilege: Don’t run containers/VMs as root unless absolutely necessary.
• Create a dedicated user inside the container/VM with only the permissions it needs.
• Specify this user when running the container/VM. For Docker, use the --user flag:

docker run --user : 

2. Capabilities (Linux): Capabilities allow you to grant specific privileges instead of full root access. For example, a container might need the CAP_NET_ADMIN capability for network configuration but doesn’t need all of root’s powers.
• List available capabilities:

  man capabilities

• Drop unnecessary capabilities when running containers/VMs using Docker’s --cap-drop ALL and then add back only the required ones with --cap-add. Example:

  docker run --cap-drop ALL --cap-add NET_ADMIN 

3. Seccomp Profiles: Seccomp (Secure Computing Mode) restricts the system calls a container/VM can make. This limits what it can do even if it has root privileges inside.
• Docker provides default seccomp profiles, but you can create custom ones for tighter security.
• Use Docker’s --security-opt flag to apply a profile:

  docker run --security-opt seccomp= 

4. AppArmor/SELinux: These are Linux kernel security modules that provide mandatory access control. They can further restrict what containers/VMs can do, even beyond capabilities and seccomp.
• Configure AppArmor or SELinux to define profiles for your containers/VMs. This is more complex but provides a strong layer of security.
5. Filesystem Isolation: Mount read-only filesystems where possible. This prevents the container/VM from modifying critical system files.
• Use Docker volumes carefully and avoid mounting host directories unnecessarily. If you must mount a host directory, consider making it read-only:

  docker run -v /host/path:/container/path:ro 

6. Kernel Version & Host Security: Keep your host kernel up to date. Vulnerabilities in the kernel can be exploited by containers/VMs, even with isolation measures in place. Ensure your host system is generally secure (firewall, intrusion detection, etc.).
7. Namespaces and Cgroups: Docker and LXC use namespaces and cgroups for resource isolation. Understand how these work to ensure proper separation of resources.
   
   • Namespaces: Isolate processes, network interfaces, user IDs, mount points, etc.
   • Cgroups: Limit the amount of CPU, memory, and other resources a container/VM can use.
8. Regularly Scan Images: Use tools to scan your Docker images for vulnerabilities before running them. This helps prevent known security issues from being deployed.
   
   • Tools like Trivy or Clair can automate this process.

Specific Considerations

• Docker: Docker’s default settings provide a reasonable level of isolation, but it’s crucial to review and configure the options mentioned above for production environments.
• LXC: LXC is closer to full virtualization than Docker. While offering stronger isolation by default, misconfiguration can still lead to security breaches. Pay close attention to AppArmor/SELinux profiles and user privileges.