4 ms·
But how do they prevent an attacker from simply opening his own connection? They can just look up the keys in the other processes.
by tinus_hn 4y ago
But how do they prevent an attacker from simply opening his own connection? They can just look up the keys in the other processes.
- scratcheee 4y agoThe 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.
- tinus_hn 4y agoThey 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.
- rockdoe 4y agoNeither of these things are possible in a sandboxed browser: the syscalls are blocked, and the filesystem isn't (fully) accessible.
- tinus_hn 4y agoWhat is the mechanism for this kind of sandboxing?
- staticassertion 4y agoNamespaces 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.
- tinus_hn 4y agoLooks cool, I clearly haven’t kept up with this.
- pcwalton 4y agoGoogle [seccomp bpf].
- pcwalton 4y agoThe syscalls necessary to do so are blocked by seccomp-bpf.