Hosted Docker isolation demo
The app stays intentionally vulnerable. Dokuru should change what the container can see and how many resources it can consume.
Demo board
Start with the WebSocket monitor, run one proof at a time, then read the live terminal stdout/stderr while Dokuru fixes are compared.
PID sleepers: 0. Run PID bomb and watch this climb.
Limit: unavailable
This is the real stdout/stderr stream from commands and resource-pressure payloads running inside the vulnerable container.
Use this card for the quick oral explanation: what user the app runs as, which namespaces it sees, and whether bind-mounted data is still writable after hardening.
uid_map starts as 0 0. After Dokuru userns-remap, root maps to a host subuid.
Before hardening, host processes are visible. After the fix, the process list is container-scoped.
Compare /proc/self/ns/* before and after Dokuru recreates the container.
Watch pids.current in the live monitor, run the PID bomb, then compare before/after Dokuru. Before hardening it can spawn many sleepers; after rule 5.29 is fixed, pids.max is lower and spawning is capped or fails earlier.
Kill sleeper processes after PID tests.
Use these exact changes as the explanation slide. The app remains vulnerable; the container boundary changes.
| UID map | Before: 0 0. After: remapped host UID range. |
|---|---|
| PID view | Before: host process list. After: only container processes. |
| PIDs | Before: many sleepers spawn. After: pids.max caps the bomb. |
| Memory | Before: unlimited or host-sized. After: explicit memory limit. |
| CPU | Before: default shares. After: explicit CPU shares/weight. |
docker inspect dokuru-lab