And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
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.Qubes OS can. Though it's not for the average users.
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.
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.
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).
> 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...)
I believe Windows is hybrid kernel not a monolithic one.
> 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.
I think you are incorrect, and your comment is not really within the site guidelines.
He has done security work on all that you mention above, and many others.
>Really?
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.