[webkit-gtk] Web process sandbox

[Michael Catanzaro]

Hi,

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.

[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.)

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.

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:

* 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.
* 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.
* 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.

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 -> now the browser is borked. To maintain this will continual 
reaction to distro-dependent bug reports. The extra security will be 
worth it, though.

Happy Wednesday,

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=110014
[2] https://bugs.webkit.org/show_bug.cgi?id=140072
[3] https://bugs.webkit.org/show_bug.cgi?id=140073
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150107/f9dfc58f/attachment.html>