All lessons Leer en español

Security in depth · Unit 22 · Lesson 14 of 44

Container isolation has dimensions

Judge a container by its actual resource grants, not its isolation label.

3 minreadyShort lesson

Helpful before thisLinux privilege escalation

See all lessons in this topic

After this lesson you can

  • Identify an unnecessary host data grant without assuming complete container or host compromise.

A container can have a narrow workspace and an unnecessary window into host data.

Isolation has several dimensions

Linux containers commonly share the host kernel. Namespaces separate selected views; control groups account for and limit resources. Neither is a complete description of authorization. User mappings, capabilities, mounts, and management access also shape the boundary.

A bind mount exposes host content to a container. Read-only access restricts modification through that mount; it still allows permitted reads. A non-root process can use resources that its effective permissions allow.

Workload identity → Isolation controls → Host resourcesWorkload identityIsolation controlsHost resources
Inspect each resource grant across the boundary. Isolation controls do not erase intentionally exposed host data.

Supplied record: a poster workshop

The fictional workshop approves a poster worker to read image templates and write finished posters. Its reviewed configuration says:

Identity: non-root, with a documented user mapping.
Resources: memory limit and separate process view.
Mounts: templates read-only; posters writable; payroll archive read-only.
Effective access review: the worker can read the payroll archive.
Management interface: unavailable to the worker.

Assume these are the active settings and there is no approved payroll dependency. This is sufficient to identify unnecessary data access. It does not prove unrestricted host administration or show that anyone actually read payroll.

Match authority to the job

Propose removing the payroll grant while preserving the two required resources. The workload owner should confirm the intended inputs before the operator changes its configuration.

Your written acceptance note should require successful poster generation and confirmation that payroll is no longer exposed through the reviewed configuration. Record the configuration version and reviewer. Avoid extending that result to every workload: another container may have different mounts, identities, or management access.

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

  1. Which finding follows from the poster worker record?

    Show the answer

    Correct answer: Its readable payroll mount exceeds the approved purpose, despite other isolation controls. The supplied record explicitly grants reading payroll data that poster generation does not need. Other restrictions do not cancel that grant.

Try it

  • WriteWrite a proposed resource list for the poster worker: required inputs, required output, and the payroll mount to remove. Add an owner approval and an acceptance condition for each change.
References