<div>Hi,</div><div><br></div><div>I've been working on sandboxing the web process, which was identified as a priority at our last planning meeting. It turns out that Intel has done a lot of work for us already by writing a backend based on libseccomp, which in turn relies on the seccomp filters mechanism that was introduced in Linux kernel 3.5. Intel's work is already in use by the EFL port, though disabled by default. [1] implements this sandbox for the GTK+ port. Note that there are several dependent bugs (with patches). With all of those patches applied, I'm able to use the sandboxed web process for everyday browsing with Epiphany, and there is no increase in layout test failures on my machine.</div><div><br></div><div>[2] enables the sandbox by default. There are again several dependent bugs that should really be addressed first, most of which do not have patches yet. (I'd like to continue working on these in the future, but in the limited time remaining on my current contract with Igalia I will focus on finishing up some unfinished work on TLS issues and responding to any reviews I get on the patches that I already posted.)</div><div><br></div><div>The seccomp filters sandbox internally uses Berkeley packet filters to restrict the set of system calls the web process is allowed to perform. (This is actually implemented in libseccomp.) When the web process performs a trapped call, e.g. open(), the kernel sends it SIGSYS. In its SIGSYS handler, the web process inspects the registers used to pass arguments for system calls, serializes them and passes them to an unconfined broker process via a private UNIX domain socket. The broker checks the arguments to determine whether the call should be permitted (e.g. anything in /usr/share is OK to load, but ~/financial_info.odt is not going to be on the whitelist), executes the call on behalf of the web process, and then returns the result (a file descriptor, in the case of open()) via the socket. There will obviously be a performance penalty for this. I have no reason to believe the sandbox will have a lower or higher performance penalty than other hardening techniques.</div><div><br></div><div>I wish I could say that application developers don't need to know or care about the sandbox, but web extensions are a huge exception. Sandboxing the web process will inevitably break web extensions. Therefore:</div><div><br></div><div>* We need to discuss new API for applications to declare what paths on the filesystem their web extensions should be allowed to access. Either (a) the UI process should be able to declare paths that web extensions should have access to, or (b) web extensions themselves should be able to do so during initialization. (a) is appropriate for browsers that do not allow third-party web extensions (like Epiphany) or browsers that want to (severely) restrict the capabilities of third-party web extensions. (b) is probably the only practical approach for browsers with third-party web extensions, though it implies trust that the web extension is not malicious. Feedback is appreciated on [3], which implements (a), but I think we may want to do (b) instead.</div><div>* We need a way to disable the sandbox (before the web process is initialized), for testing purposes. That could be the form of API, say webkit_web_context_set_web_extension_sandbox_enabled(WebKitWebContext *, gboolean), but it'd probably be nicer to use an environment variable like WEBKIT_SANDBOX_DISABLE.</div><div>* Chrome's sandbox disallows entire sets of system calls simply to reduce the kernel's attack surface. If we want our sandbox to be as tight as theirs, which I don't recommend at this stage, we will need additional API to allow particular system calls to be whitelisted. This would likely be a considerable pain for web extension maintainers.</div><div><br></div><div>Lastly, consider that the sandbox will cause the browser to break whenever our dependencies are updated to access new filesystem paths or use any new system calls that we have blocked. Some examples from the past year: malloc starts checking a new file to determine how to allocate memory, or mesa starts creating shared memory in an unexpected location -&gt; now the browser is borked. To maintain this will continual reaction to distro-dependent bug reports. The extra security will be worth it, though.</div><div><br></div><div>Happy Wednesday,</div><div><br></div><div>Michael</div><div><br></div><div>[1] <a href="https://bugs.webkit.org/show_bug.cgi?id=110014">https://bugs.webkit.org/show_bug.cgi?id=110014</a></div><div>[2] <a href="https://bugs.webkit.org/show_bug.cgi?id=140072">https://bugs.webkit.org/show_bug.cgi?id=140072</a></div><div>[3] <a href="https://bugs.webkit.org/show_bug.cgi?id=140073">https://bugs.webkit.org/show_bug.cgi?id=140073</a></div>