Bug 89874 - [WK2] [Meta] Add sandbox isolation to the WebProcess on Linux
Summary: [WK2] [Meta] Add sandbox isolation to the WebProcess on Linux
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Linux
: P1 Normal
Assignee: Nobody
Depends on: 89875 90005 110014 110365 140072
  Show dependency treegraph
Reported: 2012-06-25 06:09 PDT by Thiago Marcos P. Santos
Modified: 2020-03-18 07:14 PDT (History)
17 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Marcos P. Santos 2012-06-25 06:09:47 PDT
This meta bug will track all the effort needed for the initial implementation of the WebProcess sandbox for Linux.
Comment 1 Michael Catanzaro 2015-06-29 09:03:31 PDT
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.
Comment 2 Michael Catanzaro 2016-09-21 05:30:21 PDT
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.)
Comment 3 Philippe Normand 2020-03-18 03:00:37 PDT
I guess this can be closed now?
Comment 4 Michael Catanzaro 2020-03-18 07:14:47 PDT