mirror of
https://github.com/linuxkit/linuxkit.git
synced 2025-07-18 17:01:07 +00:00
66 lines
2.8 KiB
Markdown
66 lines
2.8 KiB
Markdown
# 2017-07-05
|
||
Time: **9am PDT** (12pm EDT, 5pm BST) [see the time in your timezone](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Linuxkit+Security+SIG&iso=20170705T09&p1=224)
|
||
|
||
Meeting location: https://docker.zoom.us/j/779801882
|
||
|
||
Announcement: [Moby project forum post](https://forums.mobyproject.org/t/2017-07-05-linuxkit-security-sig-meeting/96)
|
||
|
||
Video recording: https://youtu.be/qkp0JqtlST0
|
||
|
||
Previous meeting notes: [2017-06-21](2017-06-21.md)
|
||
|
||
## Agenda
|
||
- Introductions & Administrivia (5 min)
|
||
- Automatic privilege separation and `Memorizer` deep dive - @ndauten (30 min)
|
||
- What is automatic privilege separation?
|
||
- Introduction to `Memorizer`
|
||
- Discussion about tracking namespaces, other feedback
|
||
- demo
|
||
- Project updates (10 min)
|
||
- Next meeting: 2017-07-19
|
||
- deep dive TBD
|
||
- we can propose additional deep dives and discussion topics!
|
||
|
||
## Meeting Notes
|
||
Scribe: @mgoelzer
|
||
|
||
- Next meeting: July 19th
|
||
|
||
- Automatic Privilege Separation
|
||
- [Presentation slides here](http://nathandautenhahn.com/talks/2017-06-21_ops+memorizer-linuxkit-sig/linuxkit-sig-remark.html)
|
||
- OPS = opportunistic privilege separation (meta project)
|
||
- Our infra operates on a large, untrusted code base. Easily exploitable. “Titanic”
|
||
- Lots of layers of vulnerable code.
|
||
- Lots of code. E.g., Every version of Linux kernel is >1000 developers contributing
|
||
- Monolithic
|
||
|
||
- Strategies to address these problems:
|
||
- Replace (microkernel), or
|
||
- Harden + Separate
|
||
- Harden = making external shell more resistant to attack
|
||
- Separate = each internal component having minimal privileges so even a compromised component can do only limited damage (eg SELinux, Landlock)
|
||
|
||
- What about flipping the script? - by default everything is protected and then whitelist
|
||
- In contrast to current model where by default you have access to everything and then you bolt on protections after the fact
|
||
|
||
- Limitations of existing approaches
|
||
- No ephemeral state
|
||
- manual policy
|
||
- don’t address kernel principles
|
||
- lack of visibility into app
|
||
- (others mentioned)
|
||
|
||
|
||
- Tools / Projects:
|
||
- OPS (Opportunistic Priv. Sep.): end to end approach for fine grained security policy retrofitting
|
||
- Core hypoth: we can automatically derive policies from system behavior. Use ML to set up initial separation policy.
|
||
- Similar to an optimizing compiler.
|
||
- LINX: linux nested kernel
|
||
- kr^x: kernel randomization
|
||
- Memorizer: dynamic tracer
|
||
- Creates “maps” (like CAPs)
|
||
- CAPMAPs
|
||
- Takes kernel source -> pass it through instrumentation (piggybacking on kernel address sanitizer to hook all allocations with KASAN) -> now all allocs are hooked
|
||
- Stack is hooked through KASAN
|
||
- SLICE
|