Current State of Kernel Audit and Linux Namespaces, Looking Ahead to Containers
summary
Kernel audit currently requires a single daemon living in the initial user and PID namespaces and uses capabilities CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE to control who can run or write to it. Work moves audit toward anchoring a daemon in each user namespace with a per-user-namespace rulespace and a per-namespace queue so a container overflow cannot kill host logging. Kernel exposes namespace IDs via nsfs (plus device id) as one option; an alternative is a task-level container id inherited by children. Recent fixes already translate PID namespaces for reporting and relaxed network namespace listening, but PAM/login showed the subtle EPERM vs ECONNREFUSED behavior when availability changes.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:12History
- 2:27What is Audit
- 4:33Namespaces
- 11:11Containers
- 12:58The Problem
- 20:00The Use Case
- 22:31Usernamespaces
- 27:48Namespace IDs
- 31:43Container IDs
- 36:40Conclusion
- 39:43Who Cares
- 41:23Namespace IDs vs Containers
- 43:33Questions
- 44:43Wrapup
related talks
37mLinux Audit: Moving Beyond Kernel Namespaces to Audit Container IDs
39mLinux User Namespaces: A Blessing and a Curse
48mState of Linux Kernel Container Features
47mLinux user namespaces: a blessing and a curse
57mNamespaces for Security
35mOverview and Recent Developments: Namespaces and Capabilities
32mSecurity Namespace: Making Linux Security Frameworks Available to Containers
32mLinux user namespaces: a blessing and a curse