[arch-general] sandboxing

[Daniel Micay]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170204/a5eb0fa0/attachment.asc>