Hi,<div><br></div><div>I've been thinking more about this over the past month. In the web process, I'm currently experimenting with the approach of whitelisting only syscalls that we actually use, rather than just blacklisting filesystem access syscalls. This is closer to what Chrome does and is obviously more secure as it dramatically reduces the kernel attack surface over a more permissive sandbox.</div><div><br></div><div>* If we do a syscall whitelist, web extensions *must* have API to whitelist their own syscalls. It will simply not feasible to write and maintain a web extension otherwise. If we don't allow this then we must use a more limited sandbox that only traps a few blacklisted syscalls.</div><div>* There is no need to allow web extensions to disable the sandbox. I will just print a warning when a syscall is blocked.</div><div>* I currently see no need to allow web extensions to override how we choose to trap any syscalls that we trap. That is, a web extension should be able to say "allow this particular syscall" but need not have any finer-grained control than that. (I no longer recommend applying the patch I previously proposed.)</div><div><br></div><div>For example, we will trap filesystem calls like open() and ensure the attempted access is within a directory that the web process should be allowed to access, and the web extension need not be allowed to override this, because it is already "allowed" just with a restricted set of arguments. So the web extension can not claim write access to / for example, and there will be little incentive for a web extension author to attempt to disable the sandbox by whitelisting everything if it has no effect on how we trap filesystem syscalls. This means existing web extensions will need to be rewritten slightly, but it should not be too bad.</div><div><br></div><div>A blacklist rather than a whitelist *may* be desirable regardless, due to dependency churn outside of our control. A syscall whitelist will work reliably in stable distros like Debian and Ubuntu, but in a distro like Arch or Fedora, one of our dependencies will start using a new syscall unexpectedly and the web process will be borked until that gets fixed. I predict this will happen several times per year. But I think one person can keep up with this, and the additional security provided by the whitelist will be worth it. Again, the blacklist must be kept quite small unless we allow web extensions to whitelist syscalls.</div><div><br></div><div>Michael</div>