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?