Before we enable seccomp filters by default in the GTK+ port, we should trap more system calls. Currently, we trap open, openat, and creat so that we only allow access to particular files. Research the other system calls that operate on the filesystem to determine what we need to trap and what we don't. The Chrome sandbox blocks all system calls that Chrome doesn't use, to reduce the kernel attack space. That would be great theoretically, but I think it's too ambitious for our purposes, as it would be quite difficult to maintain unless we start bundling all of our dependencies like Chrome does. For now, let's simply trap filesystem system calls so that a compromised web process needs a separate kernel exploit if it wants to vacuum up the user's personal data.
The upcoming patch implements a whitelist of syscalls to not block; i.e. it is much more aggressive (and more secure) than the approach I recommend in comment #0. Caveats: * This increases the potential for breakage. If a whitelist of filesystem locations may not work on any distros except those we test it on, a syscall whitelist is extremely unlikely to work. * This probably makes it difficult or impossible to write web extensions. We must add API to allow extensions to whitelist syscalls (bug #140073) or else give up on whitelisting syscalls, because we're obviously not going to give up on web extensions. * The patch includes a list of calls that should be trapped but which are not yet trapped: i.e. whitelisted, but audited by the broker process. That is future work.
Created attachment 249289 [details] [GTK] SeccompFilters: Use a syscall whitelist for the web process