Security Module Stacks that Don't Fall Over
summary
Kernel supports LSM stacking (since 4.18) by changing how per-object security blob memory is allocated centrally so multiple modules can keep state, and by replacing the 32‑bit secid with a larger struct secids to carry per‑LSM identifiers and a per‑process display LSM selector. Mount‑option and netlabel semantics still conflict (SELinux vs Smack especially), network performance and labeling agreement remain problematic, but basic stacking of minor modules plus one major module works.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:13Casey Schaufler Kernel developer from the 19705
- 0:28Linux Security Module Collection of security hook
- 1:23Security Module Stack A collection of security modules
- 1:53Major Security Module
- 3:30Stacking as of 4.18
- 4:14Security Blobs
- 5:29Stacking with infrastructure managed blobs
- 6:3632 bits allows one module's data
- 7:56Identify which to use
- 10:55Unrecognized Option
- 12:46Packet Labeling
- 13:47Pushed attributes
- 15:09Netlabel Configuration
- 17:41Granularity
- 20:07Redundant purpose
- 21:51User Space
- 23:51Networking
- 24:48Process Attributes
- 25:51Think twice about using secids
- 26:43Be careful with state
related talks
33mSecurity Module Stacks That Don't Fall Over
30mLSM Stacking - What You Can Do Now and What's Next
41mThe State and Direction of LSM Stacking
15mSubsystem Update: LSM Stacking - What You Can Do Now and What's Next
23mStacked LSMs and User Space
52mLSM Maintainers Panel
01h 35mTutorial: How to Write a Linux Security Module
01h 14mLSM Updates: IMA, SELinux, AppArmor, SMACK &...