On many of these items, yes. That's the premise of the post. It's not saying "computer science could be so much better than Linux achieves". It's saying Linux fails to achieve things that other systems do achieve.
How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off.
And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today.
The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry:
> The keyboard not only works as a USB HID device, but it also has a direct UART
> cable connection to the system controller on the motherboard. By pressing the
> circle key, you can interact directly with the system controller, bypassing
> the main SoC. To give you visual feedback for this interaction, we added a
> tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check
> charger and battery cell status/health without any operating system support on
> the main SoC (even while you’re still installing an OS). The keyboard OLED and
> direct interaction mechanism has more potential future uses, like a password
> manager/wallet or notification display.
It's a non-trivial problem even with hardware assistance, without any it seems impossible.
> I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Qubes OS can. Though it's not for the average users.
It's more that it makes said sudo much less effective. You still can get tricked inside the VM or a canny enough attacker will find a bypass for VM security.
It is a somewhat higher bar though.
The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent, website ID (login, address, credit card) and data theft, phishing and scams.
None of which is prevented by Qubes.
Evil maid attacks are frustrated though if you install its extra security features.
However, it is wise to remember that security is as strong as the weakest link, so do use it if you're an admin or dev.
> The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent
Qubes OS assumes (promotes and helps with) that you do not open random links inside your banking or important VM. You can even open links automatically in a disposable VM upon a mouse click. It should help here I guess.
> bypass for VM security
VT-d virtualization was broken only once by a software attack. An it was done by the Qubes founder.
Unfortunately in reality Windows doesn’t do much better. For instance the author likes to harp on about the insecurity of X11 while on Windows GUI programs have rather similar levels of access to each other, including to APIs that have impossible to fix buffer overflows that stem from their 80s style design.
Yes there is a (semi) Secure Attention Key but it isn’t required in many cases such as while requesting consent for elevation and you can set it to required but it comes with a warning that that breaks important things (and it does).
I'm not an expert on windows or mac, but here's my run-down:
> There is no strong sandboxing in the standard desktop.
I don't know of any strong sandboxing in Windows or Mac OSX, but that could just be my ignorance.
> Most programs are written in memory unsafe languages such as C or C++
This is true on windows and Mac as well (let's include objective-c in there).
> It is a monolithic kernel written entirely in a memory unsafe language
Also true of windows and Mac.
> has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time
I don't know enough to comment on this.
> a compromised non-root user account with access to sudo is almost equal to full root compromise
Is this any different on windows or mac? Mac has sudo as well, and on windows, the main user is typically an administrator.
> X’s lack of GUI isolation
well, yeah. I don't know what the situation is like in windows and mac for this. But one of wayland's design goals is to fix this (although it also breaks things like screencasting...)
as I understand it, a hybrid kernel doesn't have a security advantage over a monolithic kernel, because the drivers/modules are still running in kernel space (as opposed to running in user-space in a true microkernel).
It works ok, with some applications on some compositors. But firefox needs to be built with patches for webrtc to work. Zoom only works on gnome (it uses a gnome-specific dbus api). Sway requires running xdg-desktop-portal-wlr, which is still very much a work in progress. afaik there isn't any way to screencast a specific window. Tl;dr; it sorta works, but not as well as it did in X.
> The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, found each month. In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time. The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough.
Are you part of some community that gets access to Windows/MacOS kernel sources to search for vulnerabilities? Or are you getting reports about such vulnerabilities from Microsoft/Apple?
I think not. I think that you're basing this argument on the amount of stuff you get to see online. Given that Linux Kernel lives under GPL that's expected.
I'm not saying that Linux Kernel is holy and we should all bow and refrain from criticism. But you're judging it completely out of context.
My last sentence answers your question framed as an accusation.
And it is not an appeal to authority, it is an appeal to published, verifiable experience. You can see this for yourself if you explore his comment history, or google for security research he published.