{"enrichment":{"faq":[{"a":"Containers Internals explains that Linux namespaces isolate process views of system resources. CLONE_NEWPID creates a new process tree; CLONE_NEWNET isolates network interfaces and routing; CLONE_NEWNS isolates mount points; CLONE_NEWUSER maps UIDs/GIDs for rootless containers. Tools like unshare and nsenter let you inspect and manipulate namespaces directly. The kernel enforces these boundaries, making processes in one namespace unable to see or interact with resources in another.","q":"How do Linux namespaces work in containers?"},{"a":"Containers Internals covers cgroups v2 as the unified resource controller for CPU, memory, and I/O. Memory limits set hard caps; when a process exceeds them, the kernel triggers OOM kill. CPU throttling enforces shares or quotas, slowing tasks rather than killing them. Debugging involves reading cgroup.stat, memory.events, and cpu.stat files. Kubernetes and container runtimes translate resource requests into cgroup settings; misconfiguration causes premature OOM or CPU starvation.","q":"What are cgroups v2 memory limits and how do they cause OOM?"},{"a":"Containers Internals describes overlayfs as a union filesystem that stacks read-only base layers with a writable top layer. Docker images are composed of immutable layers; overlayfs merges them on-the-fly without copying data. The lowerdir points to image layers, upperdir to the container's changes, and workdir to temporary state. Copy-on-write semantics mean only modified files consume extra space, making containers lightweight and fast to start.","q":"How does overlayfs enable Docker's layered storage?"},{"a":"Containers Internals explains that runc is a reference OCI runtime\u2014a low-level tool that spawns containers from OCI bundle directories. The OCI spec defines the runtime format: a config.json file describing namespaces, cgroups, mounts, and capabilities, plus a rootfs directory. runc reads this config and uses Linux syscalls (clone, unshare, cgroup_create) to set up isolation. Docker and Podman use runc under the hood; you can build minimal containers manually with runc without Docker.","q":"What is runc and how does it relate to the OCI specification?"},{"a":"Containers Internals covers seccomp-bpf as a kernel mechanism that filters syscalls via Berkeley Packet Filter rules. A seccomp profile is a JSON file listing allowed/blocked syscalls and their arguments. Tools like audit logs show blocked calls; strace reveals which syscalls a process needs. Start permissive, audit blocked calls, then tighten the profile. Kubernetes and runc apply profiles via the OCI spec; tight profiles reduce attack surface by preventing dangerous syscalls like ptrace or module_load.","q":"How do you write and audit seccomp profiles for container sandboxing?"},{"a":"Containers Internals identifies escape routes: privileged containers (CAP_SYS_ADMIN), kernel exploits, unpatched runtimes, and misconfigured seccomp. Mitigations include dropping unnecessary capabilities (use CAP_NET_BIND_SERVICE instead of CAP_SYS_ADMIN), enabling seccomp profiles, running rootless (user namespaces), keeping the kernel and runtime patched, and using read-only root filesystems. Defense-in-depth layering\u2014namespaces, cgroups, capabilities, seccomp, and AppArmor\u2014makes escapes exponentially harder.","q":"What are common container escape vectors and how do you mitigate them?"}],"shadow_tags":["process-isolation","kernel-primitives","resource-constraints","syscall-filtering","privilege-model","filesystem-layering","runtime-specification","security-hardening","rootless-execution"],"summary_rewrite":"Containers Internals covers the low-level mechanisms that power Docker and Podman: process namespaces for isolation, cgroups v2 for resource limits, overlayfs for layered storage, and seccomp-bpf for syscall filtering. Explore runc, the OCI spec, Linux capabilities, rootless user namespaces, and practical escape mitigations."},"files":[{"bytes":6550,"path":"skills/virtualization/containers-internals/SKILL.md","sha256":"0847acd3866479643b04cffaa2372eb1f28cbd11b307f05f0d0b7f574a06caba","url":"https://skillfed.io/files/mohitmishra786/low-level-dev-skills/containers-internals/abe27014/SKILL.md"}],"id":"mohitmishra786/low-level-dev-skills/containers-internals","links":{"html":"https://skillfed.io/mohitmishra786/low-level-dev-skills/containers-internals","md":"https://skillfed.io/mohitmishra786/low-level-dev-skills/containers-internals.md","repo":"https://github.com/mohitmishra786/low-level-dev-skills"},"meta":{"agents_supported":[],"first_seen":"2026-07-28","forks":19,"language":"JavaScript","last_updated":"2026-06-27","license":"MIT","name":"containers-internals","publisher":"mohitmishra786","stars":148},"relations":{"similar":[{"id":"yaklang/hack-skills/container-escape-techniques"},{"id":"hypnguyen1209/offensive-claude/privesc-linux"},{"id":"martinholovsky/claude-skills-generator/sandboxing"},{"id":"blacklanternsecurity/red-run/container-escapes"},{"id":"blacklanternsecurity/red-run/linux-kernel-exploits"},{"id":"yaklang/hack-skills/sandbox-escape-techniques"},{"id":"hypnguyen1209/offensive-claude/container-k8s-escape"},{"id":"mohitmishra786/low-level-dev-skills/kernel-security"},{"id":"yaklang/hack-skills/linux-security-bypass"},{"id":"JosiahSiegel/claude-plugin-marketplace/docker-platform-guide"}]},"slug":{"owner":"mohitmishra786","repo":"low-level-dev-skills","skill":"containers-internals"},"version":"abe27014"}