Flatpak just disclosed a nice zero day in our sandbox: https://github.com/flatpak/flatpak/security/advisories/GHSA-67h7-w3jq-vh4q There is a massive warning comment in flatpak-run.c to make sure anyone editing their seccomp filters knows they need to coordinate with other projects that share the same filters before disclosing vulnerabilities, but... well, it didn't happen. Oh well. To prevent this from happening again, we need to split the affected code out of flatpak so that it becomes more obvious that it is shared with multiple projects: https://github.com/flatpak/flatpak/issues/4466. Anyway, the problem is the web process can delete the .flatpak-info file that we create in the root of its filesystem namespace. That's not intended, and we do need to request a CVE (I'll do this next week), but it's probably not the end of the world either, as nobody seems to be able to immediately think of anything that could directly go wrong. Certainly it's not a normal full sandbox escape. The web process doesn't have direct D-Bus access, so it can't talk directly to desktop portals -- those look for .flatpak-info in the filesystem namespace of the xdg-dbus-proxy process, which is trusted -- so the badness seems to be limited to communication via Unix sockets that are mounted inside the sandbox, which hopefully do not trust their peers anyway. That said, we do need to address this by copying the recent changes to flatpak's sandbox filters into WebKit. We also need to stay tuned to future changes to the flatpak filters.
<rdar://problem/84064163>
Created attachment 440804 [details] Patch
Where and how is Syscalls.h used? Maybe I missed it.
Comment on attachment 440804 [details] Patch It's used by SCMP_SYS. I found its definition in seccomp.h: #define SCMP_SYS(x) (__SNR_##x)
Comment on attachment 440804 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=440804&action=review > Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:737 > + { SCMP_SYS(clone3), ENOSYS, nullptr }, E.g. this line here... > Source/WebKit/UIProcess/Launcher/glib/Syscalls.h:114 > +#ifndef __SNR_clone3 > +# define __SNR_clone3 __NR_clone3 > +#endif ...might depend on this definition here.
Ping reviewers
Comment on attachment 440804 [details] Patch Seccomp is about the worst possible ever design for such a feature (for comparison, check pledge/unveil in OpenBSD and marvel!), but we have no other remedy than to live with it 🤷♂️️
Committed r284451 (243211@main): <https://commits.webkit.org/243211@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 440804 [details].
I've requested a CVE.
We received CVE-2021-42762.