This is a bit buried at the bottom, but:<p>> For Linux users, we removed the connection from content processes to the X11 Server, which stops attackers from exploiting the unsecured X11 protocol.<p>It's hard to overstate how much of a benefit this is in terms of security for those on Linux. Any application with access to the X11 socket effectively has the keys to the kingdom, because it can hijack other applications, including those running at higher privileges, at will. (There have been halfhearted attempts to address this over the years, but nothing that's been effective or widely adopted.) The only real solution for desktop app security on Linux is to forbid direct access to X11 entirely, and so it's a huge deal that Firefox is now able to do this.<p>In general, doing this sort of thing is a monumental undertaking for large applications like Firefox. Kudos to my former colleagues for pulling it off.
I firmly believe that isolation is the future of endpoint security and I like experimenting with Mandatory Access Control (MAC) on Linux. Tomoyo is my favorite major MAC/LSM in the Linux kernel.<p>If you have a newer kernel (5.13 or greater), you may like to experiment with landlock. It's pretty cool and unlike FireJail, no suid required. Here's a landlock wrapper for Firefox:<p><a href="https://github.com/62726164/misc/blob/main/go/landlock/firefox/main.go" rel="nofollow">https://github.com/62726164/misc/blob/main/go/landlock/firef...</a><p>I'd like to learn more about open source/free Windows and MacOS MAC tools. If you know of any, please post about your experience with them.<p>Edit: This Windows functionality seems similar to seccomp and pledge: <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-process_mitigation_system_call_disable_policy" rel="nofollow">https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-...</a>
It's a real shame that platform native widgets had to be sacrificed for this to work. The easy way out was to switch to arbitrary app-drawn widgets across all platforms (which Firefox did for all basic DOM HTML elements); the "we'll do one better" alternative is to use app-drawn <i>imitations</i> of the system-native widgets (a la Qt) which Firefox is now doing for the scrollbar. But no one ever gets these widgets right (unnatural scrolling, non-identical behavior when clicking in the gapped region, different scrollable-to-nonscrollable widget ratios, colors not respecting certain subtle theming choices, etc, etc.<p>I wonder if there was an alternative specifically for the scrollbar here - some way of obtaining an outer "shell" (via win32k, but then basically "orphaning" it so that you can't do anything besides kill it when you're finished) that just provides the window with an empty scrollable element that is then populated by the restricted process.<p>That ship has really sailed though; I think the days of native widgets are quickly coming to an end.
So here we have a feature of Windows 8/10, which prevents the system calls of Win32U/Win32K from being called.<p>When you write a Windows program, you call APIs from User32.dll, GDI32.dll, and Kernel32.dll. Those are the user mode libraries, and the main entry point to call the Windows API functions.<p>What's actually inside of those? User32 and GDI32 are pretty much stubs. Mostly, they have a small amount of code, then proceed to call functions in Win32U.dll. Then Win32U.dll makes system calls, causing Win32k (Kernel Mode) to carry out the functions. So everything from BeginPaint to GetWindowText is going to be a system call that's placed from within Win32U, then handled by Win32K.<p>Meanwhile, Kernel32.dll is a user-mode library (despite the name being "kernel32"), which mostly makes calls to NTDLL.dll. Then NTDLL makes system calls that get handled by kernel-mode components.<p>The isolation thing that Mozilla is using here does not stop the NTDLL system calls that Kernel32.dll uses, just the calls to Win32U/Win32K (GDI32.dll and User32.dll). So there needs to be other mitigation methods in place for the Kernel32/NTDLL stuff, such as reduced user privileges.<p>But preventing all the Win32U/Win32K stuff from being called does greatly reduce the attack surface.
I'm so glad they're working on this instead of unimportant minutiae like copy/cut frequently outright refusing to deposit its contents in the system clipboard on all three major platforms, or the browser simply freezing for up to ten minutes after the system wakes up from sleep while it syncs all changes made since then.