On Fri, 2017-02-03 at 17:49 +0100, Bart De Roy via arch-general wrote: > Error verifying signature: parse error > --pyi53mwzyx2s2ll6 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > hello > > I've been postponing looking into browser isolation > since I started using Wayland about a year ago. > > Does anyone have pointers, experiences or comments on > this topic with regard to Xwayland? If I'd want to > disassociate parts of chromiums execution context, > what are common, good options? > > cheers, Bart > > --pyi53mwzyx2s2ll6-- The vast majority of Chromium's code already runs in far tighter sandboxes than can be made externally via namespaces, MAC, etc. Using an outer sandbox can help in the case where a sandbox bypass exploits the browser's broker process responsible for managing the renderers. The easiest way out is often a kernel exploit despite the extremely restricted system call whitelist which doesn't even include calls like open(...). If you want to strength the existing sandbox, a hardened kernel goes a long way to mitigating one of the two primary attack vectors for escaping the sandbox. There might be some value in containing the file access of the outer sandbox even if it's not really contained, because an attacker might only be able to influence it to incorrectly open any file, etc. if they only have code execution in a renderer without a code execution exploit for the outer part. I don't think there have been many bugs like that though, it's mostly just a full sandbox escape in which case the outer sandbox would actually need to contain usage of X11, pulseaudio, dbus, etc. So you definitely need more than simply MAC or namespaces + X11 / pulse access granted. Indirect access to X11 via another instance of it isn't great either.
Attachment:
signature.asc
Description: This is a digitally signed message part
