CEH Practice Question: Advanced Topics: Wireless, Cloud, IoT, Cryptography

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  A process running inside the container with CAP_SYS_ADMIN capability

  Why this is correct

  A process running inside a container with the CAP_SYS_ADMIN capability is a critical security vulnerability. This capability grants extensive privileges, often likened to root access on the host system, allowing operations such as mounting filesystems, creating device nodes, and loading kernel modules. An attacker can leverage CAP_SYS_ADMIN to break out of the container's isolation by manipulating the host's kernel or filesystem, effectively gaining control over the underlying host machine.

• ✓

  The container is running in privileged mode

  Why this is correct

  When a container is run in "privileged mode," it essentially disables most of the security restrictions imposed by the container runtime, such as AppArmor, SELinux, and capability drops. This mode grants the container direct access to all host devices, including /dev/sda or network interfaces, and allows it to load kernel modules. Consequently, a privileged container can interact with the host kernel and hardware almost as if it were running directly on the host, making container escape trivial.

• ✓

  The container is using a hostPath volume that mounts the host's /var/run/docker.sock

  Why this is correct

  Mounting the host's /var/run/docker.sock file into a container provides the container with direct access to the Docker daemon's API endpoint. This socket is the primary communication channel for managing Docker containers and images on the host. By interacting with docker.sock, a malicious container can issue commands to the host's Docker daemon, such as creating new privileged containers, stopping existing ones, or even executing commands directly on the host, thereby achieving a complete container escape.

• ✗

  The container has a read-only root filesystem

  Why it's wrong here

  A container having a read-only root filesystem is a security hardening measure designed to prevent an attacker from modifying critical system files or installing persistent malware within the container. While this practice significantly reduces the impact of a compromise *within* the container by limiting write access, it does not inherently prevent a container escape. An escape often exploits kernel vulnerabilities or misconfigurations that allow access to the host, regardless of the container's filesystem write permissions.

• ✗

  The container is running as a non-root user

  Why it's wrong here

  Running a container process as a non-root user is a fundamental security best practice that limits the privileges available to applications *inside* the container, reducing the blast radius if the application is compromised. However, this measure alone does not prevent container escape if other vulnerabilities exist. For instance, a non-root user could still exploit a kernel vulnerability, a misconfigured capability, or a mounted sensitive host path to elevate privileges and break out to the host system.

Go deeper

Related to this question