CAS-004 Security Engineering Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Apply a seccomp profile that allows only the system calls the application actually uses and denies the rest by default.

  Why this is correct

  A default-deny seccomp profile removes access to the large majority of system calls a process never needs, shrinking the kernel interfaces an attacker can abuse from inside a compromised container. Because it is enforced per process by the kernel, a successful application exploit cannot pivot to unneeded calls such as those used to load modules or manipulate namespaces, directly reducing escape options.

• ✗

  Run the container runtime with the Docker socket mounted into every container so the platform can manage sibling containers.

  Why it's wrong here

  Exposing the container runtime socket inside a container grants effective control of the host's container engine, which is a well-known and severe privilege escalation path rather than a hardening measure. A process with socket access can start privileged containers that mount host paths, so this directly undermines the goal of preventing escapes to the host kernel.

• ✗

  Disable mandatory access control frameworks such as AppArmor or SELinux so the application is not blocked by policy denials.

  Why it's wrong here

  Disabling mandatory access control removes a defense-in-depth layer that confines processes even after they gain elevated privileges inside the container. Policy denials usually indicate an overly broad application or an overly strict profile, and the correct response is to tune the profile, not to switch off the mechanism that restricts what a compromised process can touch on the host.

• ✗

  Set the container to run as the root user inside its namespace to avoid file permission problems during deployment.

  Why it's wrong here

  Running as root inside the container, even with user namespace mapping, leaves the process with maximum in-container privilege and makes many escape techniques far more effective. Combined with a missing user namespace remap, root in the container can map to root on the host, so this choice increases risk instead of reducing the kernel attack surface.

• ✓

  Drop all Linux capabilities and add back only the specific ones the application requires.

  Why this is correct

  Capabilities split root's monolithic power into discrete privileges, so dropping the full set and re-adding only what is needed removes abilities like mounting filesystems, changing network configuration, or loading kernel modules that are commonly abused in container escapes. Least-privilege capability sets mean a compromised process simply lacks the authority to perform host-altering operations.

Go deeper

Related to this question