[pengaru]

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.

[0] https://www.crowdsupply.com/mnt/reform

[fsflover]

> 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.

[AstralStorm]

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.

[fsflover]

> 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.