Lab: Linux capabilities

DISCLAIMER: This lab uses --privileged for comparison only. Use a disposable Linux VM. Do not run privileged containers on production or shared hosts.

This lab shows how Linux capabilities map into containers, how to drop and add them with Docker flags, and how --privileged compares to a tuned capability set. Learn how default containers run with restricted Linux capabilities, while –privileged grants full capabilities (=ep), enabling direct access to host devices and effectively removing isolation.

Prerequisites

• Docker installed (docker version works).
• Permission to run Docker commands (root or docker group).

The Dockerfile below installs iputils-ping and libcap2-bin inside the image. You do not need those packages on the host unless you want them for other reasons.

Hands-on Lab

Capabilities and Device Access (Privileged vs Default)

• Run default container and inspect capabilities.

docker run -it --rm alpine sh -c "apk add --no-cache libcap >/dev/null 2>&1; capsh --print"

• Shows a limited capability set (no cap_sys_admin, no raw device access).

• Attempt disk listing in default container.

docker run -it --rm alpine sh -c "apk add --no-cache util-linux >/dev/null 2>&1; fdisk -l"

• Typically fails or shows minimal info due to missing capabilities/devices.

• Run privileged container and inspect capabilities.

docker run -it --rm --privileged alpine sh -c "apk add --no-cache libcap >/dev/null 2>&1; capsh --print"

• Shows full capability set (effectively all caps enabled).

• List host disks from privileged container.

docker run -it --rm --privileged alpine sh -c "apk add --no-cache util-linux >/dev/null 2>&1; fdisk -l"

• Reveals host block devices and partitions (e.g., /dev/sda, /dev/sdb).

Impact: Privileged containers gain direct access to host devices and kernel interfaces.

• Next step: Theory: Image CVE scanners, then Lab: Trivy image scan.