Linux Audit: Moving Beyond Kernel Namespaces to Audit Container IDs
summary
Kernel lacks a container concept so audit moves from namespace guessing to a concrete au64 container ID stored per task via a new /proc/<pid>/container_id read/write entry with ACLs, inherited by children and added to network-namespace lists for attribution. Design includes two new audit records, routing to multiple audit daemons each with its own rule space and queue, a 64-bit ID choice to balance collisions and kernel compare cost, four prototype revisions already posted and pending final review.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 0:32Who am I
- 4:53What are Containers
- 6:27Whats the problem
- 10:09History
- 13:16Network namespace
- 15:56Access controls
- 19:45Audit container identifier
- 23:26Network namespace issues
- 25:26Conclusion
- 27:22Contact Information
- 28:02Nested Containers
- 29:51Overheads
- 32:41Other Developers
- 34:44PTags
- 36:11Log Aggregation
related talks
46mCurrent State of Kernel Audit and Linux Namespaces, Looking Ahead to Containers
22mAudit in Kubernetes Now, and in the Future
47mNamespacing the Linux Integrity Measurement Architecture
27mRethinking Compliance in a Containerised World
32mSecurity Namespace: Making Linux Security Frameworks Available to Containers
39mLinux User Namespaces: A Blessing and a Curse
24mBridging BPF LSM and the Linux Audit Subsystem
08mIn Containers We Trust? Building Trust in Containerized Environments