A transit engagement includes Linux container breakout in scope. Conceptually, which container traits should the tester enumerate first?
Select an answer to reveal the explanation.
Short Explanation
Container breakout hunts start with "how Swiss-cheese is this jail?"—privileged mode, fat host mounts, and oversized capabilities. Those traits punch holes in isolation way faster than logos or IDE themes. Enumerate the dangerous flags first.
Full Explanation
When a transit engagement includes Linux container breakout in scope, enumeration should start with traits that undermine isolation: privileged container flags, dangerous host mounts (especially docker.sock or host root filesystems), and excessive capabilities. Those properties turn 'container foothold' into 'host foothold' risk for civic workloads.
Wallpaper themes and ASCII logos are not security enumeration targets. Developer IDE dark mode is irrelevant. The vendor registry marketing slogan does not describe isolation posture.
Exam caveat: also note user namespaces, seccomp, and AppArmor/SELinux profiles as complementary isolation signals—not only privileged:true.
Operational check: inspect container runtime configuration for privileged mode, mounts, and capabilities within authorization, document breakout-enabling settings, and recommend least-privilege pod/container specs for transit platforms. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same finding class still applies under the estate's current patch and configuration baseline.