Hacker News Reader

But how do they prevent an attacker from simply opening his own connection? They can just look up the keys in the other processes.

View on HN

The syscalls necessary to do so are blocked by seccomp-bpf.

The isolated content processes shouldn't have access to the other processes memory. There might be shared memory regions, but it seems unlikely they'd store the keys to the kingdom in shared memory.

They are owned by the same user so they probably have access to everything the other processes have. And they can probably just read the access token from the environment which is accessible through the /proc filesystem.

Neither of these things are possible in a sandboxed browser: the syscalls are blocked, and the filesystem isn't (fully) accessible.

What is the mechanism for this kind of sandboxing?

Namespaces let you create isolated views of the file system, isolated views of processes (ex: if you are in a new pid namespace and run 'ps' you only see yourself), users, network interfaces, etc.

I'm not sure what Firefox does, I believe they use the Chromium sandbox, and I'm way out of date on that. It used to do some filesystem setup like hardened chroots, but I would assume that's been supplanted by fs namespacing.

Looks cool, I clearly haven’t kept up with this.

Google [seccomp bpf].

Reply on news.ycombinator.com