Linux Security APIs and the Chromium Sandbox
summary
Chromium’s multiprocess layout is mapped to concrete Linux primitives: the browser forks/clones child processes and uses clone + user/pid/net namespaces to give renderers no network, isolated PIDs and fake root; seccomp filters use seccomp‑bpf whitelist with PR_SET_NO_NEW_PRIVS for syscall restriction; a neat chroot via clone_fs trick makes the parent lose filesystem access; GPU remains less restricted; kernel/version differences and tests drive which features activate and Chromebooks add cgroups per tab for resource control.
AI-written summary · about
chapters (16)
- 0:00Start
- 3:37describe the process architecture of a chromium based browser
- 5:01launches the vivaldi bin
- 5:52start off by starting your initial browser
- 8:06look at the linux security api
- 11:51enter a username space inside of that main space
- 16:33make a thread on linux
- 31:19protect against many types of security vulnerabilities
- 32:04set up a second filter
- 37:53copying this binary representation into this structure the sock filter on the stack
- 39:53the idea of a browser sandbox
- 41:10drop all access to the filesystem
- 42:34chroot to a process specific directory
- 46:25run chromium on a chromebook
- 47:36freeze all of the background tabs
- 49:51create a user name space unprivileged inside of that namespace
related talks
46mLinux Security APIs and the Chromium Sandbox
50mLinux Security and How Web Browser Sandboxes Really Work
01h 25mSandboxing a Linux Application
34mLinux for Chromebooks: Secure Development
42mSandboxing a Linux application
35mIsolating GPU access in its own process
32mLinux user namespaces: a blessing and a curse
01h 02mSandboxing a Linux Application