If you are willing to pay a little, requiring Yuibikey press for sudo is supported [0].

If you don't want extra hardware, you can use "pam_exec" PAM method to read second factor (like PIN) from "/dev/input/by-id/...". This'll read from specific input device directly, bypassing GUI session or any other processes controlled by non-root user. Or use a "chvt" call instead, and you can have a secure display output too.

But while this will prevent "evil sudo" from capturing your password, it won't prevent "evil sudo" modifying the commands you want executed (the same problem exists with Windows SAK / Escalation prompt: you know you are approving some action, but it is not clear which action exactly).

I guess Linux has a unique advantage in that "sudo" is designed for user-readable commands -- so in many cases, confirming the command on un-tamperable output will be enough for safety (for example, "sudo apt install foo" will be safe this way). But you'd still want to make sure you are vigilant at all times -- if you have a habit of typing "curl ... | sudo sh", then no type of SAK process will save you from evil sudo.

[0] https://support.yubico.com/hc/en-us/articles/360016649099-Ub...

I don't think any of your solutions provide that capability.

They do not provide "some action only kernel can detect" -- but I don't think you need this. Linux has strong enough user isolation that userspace programs running as root are as good as kernel is. Let me elaborate on that:

From security standpoint, they are equivalent. If you get kernel access, you can start a userspace root process. If you can get a root process access, you can modify kernel. So being "kernel only" does not really have that many advantages over privileged process.

And Linux kernel provides pretty strong user isolation. In particular, there are two subsystems in Linux which (AFAIK) are not present in windows, and which makes the safe userspace login possible:

- The system does not have a single "screen", instead it has multiple "virtual terminals". All the display/input devices are tied to single virtual terminal, and switching to a different virtual terminal completely deactivates the other one. So, for example, you might have your user's regular session on VT 7. If you somehow switch to the VT 2, then no matter what that user session does, it can no longer affect the display nor read from keyboard until you switch back.

- The kernel provides direct access to the input devices to the root user, via /dev/input/ file. This access happens before regular input layers, and cannot be affected by non-root users at all. So while a user's app can proxy the TTY input, or set up a global keygrab for the X session, or install a strange keyboard layout, this will not affect those /dev/input files at all.

So have a root process that monitors /dev/input/* and switches to a different tty when a designated SAK key is presses. And you have your "real GUI" solved, no kernel needed.

Agree?

Nope, it's still there. It may require being joined to an AD Domain with the relevant setting toggled, though.