About Madaidan's Insecurities

[ghost]

So, I bumped into this and there seems enough evidence to not use Firefox at all but he/she doesn't mention anything about Webkit based browsers. I am using the default eOS browser, GNOME Web, and now wondering if it is secure enough to use daily. What are your opinions on this? Is it just as insecure as Firefox on Linux or does WebkitGTK provide something that Firefox can't offer atm?

[TingPing]

This is a general answer because its an extremely broad question.

Largely speaking neither Firefox nor WebKit have as many mitigations for various security issues as Chromium has.

Both Firefox and WebKit do take security seriously and do implement many mitigations and both support sandboxing in various degrees. I would not call either highly risky. However they will likely always trail behind Chromium in a lot of security features.

[ghost]

Thanks a lot, I just needed a very broad answer anyway because my threat model is rather low.

[mcatanzaro]

TL;DR: If you're a journalist, political dissident, or cybercriminal, you should probably be using Chrome. I think WebKit security is good enough for most users though. Most desktop Linux applications have no sandbox at all.

• Site isolation: important, but very hard. Some groundwork is in place ("process swap on navigation") for a few years now, but there are edge cases and until all edge cases are fixed there's not much security benefit. In general, we are not close, and I haven't seen progress in a couple years, so that probably puts us in a comparable or worse position to Firefox. Apple has been participating in standards discussions, though, because there's no way to do site isolation without changes in web-exposed APIs (e.g. website A can no longer open website B and then script it, because they run in separate processes).
• X11 sandbox hole: just don't use X11. Yes the Chrome solution is theoretically better, but nobody is going to spend time on securing WebKit under X11 because it is legacy tech. There is no sandbox hole for X11 if you run in a Wayland session.
• PulseAudio sandbox hole: hm, we need to fix this. In Fedora world, we've had two releases with no more PulseAudio, but the sandbox hole still exists. Ideally we would have a way for flatpak to open the hole only if the host system is really running PulseAudio. Beyond that, I don't think it's worth investing in further because like X11, PulseAudio is legacy tech and time invested into locking down access is time wasted in the long run.
• seccomp: I actually prefer Firefox's approach. Chrome's seccomp filters are way too fragile. There is a balancing act between security and practicality, and Chrome's way only works if absolutely all dependencies including libc.so are built as a static lib and bundled into Chrome. Chromium breaks all the time whenever glibc or any of its dependencies decide to use a new syscall. Trying to protect against Linux kernel bugs is outside the scope of the WebKit sandbox. Now, if you are a spy or journalist or dissident at high risk of being attacked by a nation state, then you probably want a sandbox that's as paranoid as possible. But that is not suitable for WebKit, because it would only ever be sure to work on the developer's computer, and users would constantly be reporting bugs.
• Process separation: we're basically in the same boat as Firefox. We do have a "network" process, but it's really a god process with unlimited permissions that does way more than networking. We just don't know what else to name it. GPU process is on the way eventually. Beyond that, I wouldn't expect more processes since it's very expensive.
• ACG/CIG: I've never heard of these, and they seem to be Windows-specific.
• CFI: this is up to distros to decide how they compile their packages, it's not a choice made by upstream software vendors. Currently no distros build any applications with CFI, so Firefox and WebKit are no different from anything else.
• Untrusted fonts: I'm a little bamboozled by this one. Fonts need to work? I don't doubt that malicious fonts can exploit the web process, but they should be confined by the sandbox if so. There are many many other ways to exploit the web process. This is why sandbox is important.
• JIT hardening: I don't know about this.
• malloc hardening: WebKit's malloc is the most paranoid I have ever seen. I don't understand most of what it does. Good to see Chrome has something similar.
• Automatic variable initialization: another choice of how distros compile packages, not of individual applications. It's a new feature of GCC 12, and we're debating turning it on in Fedora 37. It's a no-brainer security improvement.

I will say that our sandbox (developed by TingPing, thank you ;) has a very good track record. I'm only aware of two sandbox escapes total, and the scope of the most recent one was so limited that I'm not sure whether you could have really done anything bad using it. The other was very serious, but quite inventive and not something I would have seen coming. Ultimately it's the sandbox escapes that attackers are really looking for. All of the security mitigations discussed above are designed to make it harder to attack WebKit, but a sufficiently-motivated attacker is always going to succeed at that. Breaking out of the sandbox should be very hard, though.

[ghost]

Thanks a lot for your very detailed answer, very clarifying.

just don't use X11

But I have to ask; is this even an option on elementary? I know it is being worked on but what is the current situation on OS 6?

[mcatanzaro]

I don't know.

[TingPing]

It currently only supports X11.