Monitoring, Logging and Runtime Security →hardMultiple Choice

CKS Monitoring, Logging and Runtime Security Practice Question

A cluster uses containerd and a security team wants to block containers from loading kernel modules. They apply a pod with securityContext.seccompProfile.type set to Localhost and a profile that returns SCMP_ACT_ERRNO for the init_module and finit_module syscalls. The pod starts but a test binary still loads a module. Which is the most likely cause?

⚠ Common exam trap

The trap here is assuming that listing a syscall with an errno action always blocks it, when an earlier matching allow rule or a retained capability can let the call succeed.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The container process runs with CAP_SYS_MODULE and the seccomp profile's default action is SCMP_ACT_ALLOW, so the errno rule was placed after a broader allow rule that matched first.

Seccomp applies the first matching rule, so a broad allow placed before the errno rule for init_module and finit_module neutralizes the block. Keeping CAP_SYS_MODULE also lets the process attempt module loads. Ordering the deny rules first and removing the capability ensures the filter actually stops module loading in this container.

Answer analysis

Option-by-option breakdown

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

✗
The seccomp profile must be stored in the container image rather than referenced by the pod, so the runtime ignored it.
Why it's wrong here
Localhost seccomp profiles are referenced by name from the pod securityContext and resolved by the runtime from a file on the node, not from inside the image. The runtime does honor a correctly loaded profile. The failure is not caused by the profile's storage location but by rule ordering and the retained capability.
✗
The pod needs privileged: true for the profile to be enforced, since restricted pods skip seccomp filtering.
Why it's wrong here
Privileged containers are the ones that often weaken confinement, not the ones required for seccomp. Setting privileged: true would grant broad capabilities and make module loading easier, not harder. Restricted pods with a proper seccomp profile are enforced normally, so this change would worsen the security posture rather than fix it.
✗
Seccomp filters cannot block init_module or finit_module because those syscalls are resolved by the kernel before the filter runs.
Why it's wrong here
Seccomp filters run on every syscall entry and can absolutely block init_module and finit_module by returning an errno. There is no kernel exemption that bypasses the filter for these calls. The premise is incorrect; the observed behavior stems from profile composition and the container's capabilities, not from an inherent seccomp limitation.
✓
The container process runs with CAP_SYS_MODULE and the seccomp profile's default action is SCMP_ACT_ALLOW, so the errno rule was placed after a broader allow rule that matched first.
Why this is correct
Seccomp evaluates rules in order and applies the first matching rule, so an early broad allow for the syscall group can shadow the later errno rule. Combined with CAP_SYS_MODULE, which grants the capability needed to load modules, the container bypasses the intended block. Reordering the deny rule above the allow and dropping the capability closes the gap.

Go deeper

CKS Monitoring, Logging and Runtime Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question