Namespaces for Security
summary
Namespaces partition kernel resources so processes get isolated views of mount, network and user namespaces and others (pid, uts, ipc). Creation uses clone/unshare/setns and modern kernels (3.8+) include user namespaces though userns currently requires turning off some network filesystems until conversions land. systemd-nspawn is used to build lightweight containers in the demo: separate /proc, private /tmp, distinct pids and per-namespace iptables, letting an update checker be confined to a read-only mount and limited network reach. Mount propagation modes (private/shared/slave) remain a common pitfall.
AI-written summary · about
chapters (27)
- 0:00Introduction to namespaces
- 1:02Security threats and effects
- 2:38Network services and attacks
- 4:27Attacker goals and capabilities
- 5:57System resource exploitation
- 7:35Local privilege escalation
- 8:44Linux security technologies
- 10:20Capabilities and sandboxing
- 11:46History of namespaces
- 14:01Partitioning resources
- 16:15Use cases for namespaces
- 17:31Types of namespaces
- 20:06User namespaces explained
- 22:18System configuration and API
- 24:09Namespace management tools
- 26:01Technical diagram analysis
- 28:20Referencing namespaces
- 29:36Mount namespace propagation
- 32:43Live demonstration
- 34:45Container vs host view
- 38:28Network namespace isolation
- 39:53Security examples and use cases
- 42:48Audience Q&A
- 45:44Comparison with FreeBSD Jails
- 48:57Container vs namespace concepts
- 50:28Final security considerations
- 52:53SELinux and conclusion
related talks
01h 03mLinux Namespaces for Fun and Isolation
54mContainers unplugged: Linux namespaces
47mLinux user namespaces: a blessing and a curse
42mWhat's New in the User Namespace
32mSecurity Namespace: Making Linux Security Frameworks Available to Containers
39mLinux User Namespaces: A Blessing and a Curse
54mUnderstanding user namespaces
25mIsolate the Users! Supporting User Namespaces in K8s for Increased Security