Bug 89874 – [WK2] [Meta] Add sandbox isolation to the WebProcess on Linux

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Thiago Marcos P. Santos]

This meta bug will track all the effort needed for the initial implementation of the WebProcess sandbox for Linux.

[Michael Catanzaro]

FYI, I've found seccomp filters to be very fragile for sandboxing WebKit (note that they are intended for sandboxing bytecode, not web browsers) and I don't recommend enabling this for EFL yet (especially since the current syscall blacklist covers only three syscalls and provides little real security). The next step is to investigate how more robust sandboxes (like systemd-nspawn, or the non-seccomp layer of the Chromium sandbox) operate, perhaps using e.g. filesystem namespaces instead of trying to audit every filesystem access with seccomp filters. We definitely want to use seccomp filters as part of our sandbox, for sure, but probably in a much reduced scope, and quite possibly not in SIGSYS mode.

A historical example of a problem that would have broken WebKit had we been using my seccomp whitelist: libxshm in Fedora 21 originally put shared memory in /var/tmp, but after a kernel update brought the new memfd_create() syscall, switched to using that instead. That's absolutely reasonable as it would be absurd for the needs of WebKit's sandbox to dictate how we update low-level components like libxshmfence that should not know anything about WebKit, but memfd_create() was not on my syscall whitelist and could not have been (since it didn't previously exist), which would have broken WebKit for all users (had seccomp filters been enabled and my whitelist in use). There will just be more incidents like this in the future, except they will be real incidents where WebKit just stops working on particular distros. I predict downstreams will simply disable the sandbox if we don't have the resources to respond rapidly to distro-specific bug reports (we don't). This particular problem would have been avoided by using a syscall blacklist instead of a whitelist (which is what WebKit trunk does), and that is definitely a possibility to consider, but that makes it much harder to write the sandbox.

[Michael Catanzaro]

I removed the seccomp filters code several months ago.

Sandboxing is no longer interesting to GNOME, since we plan to distribute 100% of our apps as Flatpaks, and any WebKit sandbox would likely need to be disabled in favor of the Flatpak sandbox. However, other users of WebKit would surely appreciate having a sandbox, so I'll leave this bug open. (seccomp-filters cannot be the primary security mechanism, though, for the reasons mentioned above.)

[Philippe Normand]

I guess this can be closed now?

[Michael Catanzaro]

Yes