Linux Security and How Web Browser Sandboxes Really Work
summary
Explains how Chromium-based browsers build a Linux sandbox by combining user+PID+net namespaces with capability dropping so renderer processes think they are root but are isolated from the host, adding a seccomp‑BPF whitelist that runs in-kernel for every syscall, and using a clever clone+CLONE_FS chroot trick (child chdirs then deletes the directory so parent loses filesystem access). Describes separate GPU broker, set_no_new_privs, Yama/ptrace limits, and why debugging and crash reporting become painful.
AI-written summary · about
chapters (14)
- 0:00Start
- 9:48BROWSER PROCESS
- 10:22ZYGOTE PROCESSES
- 10:51RENDERER PROCESSES
- 11:32GPU PROCESSES
- 15:25CAPABILITIES NAMESPACES
- 17:17CHROOT
- 17:56SECCOMP
- 18:33RESOURCE LIMITS
- 20:20SETUID/SETGID
- 21:39CGROUPS
- 22:55PROCESS GROUPS
- 27:45WINDOWS OF OPPORTUNITY : FORK
- 41:41SANDBOX CONSTRUCTION
related talks
46mLinux Security APIs and the Chromium Sandbox
55mLinux Security APIs and the Chromium Sandbox
01h 25mSandboxing a Linux Application
42mSandboxing a Linux application
32mLinux user namespaces: a blessing and a curse
01h 02mSandboxing a Linux Application
23mOverview and Recent Developments: seccomp and Small Linux Security Modules
38mSandboxing in Linux with zero lines of code