Authentication using SysRq

Question

The general idea here is the feasibility of adding Windows UAC-like "consent prompts" to a Linux system, designed in such a way that cannot be bypassed in software. Giving consent should only be doable if one is physically at the keyboard. Any process can request elevated privileges.

The specific idea is that a command expecting a password (such as su, or even more application-specific commands like gradm, used for authenticating to the administrator role when using RBAC for access controls) is vulnerable to a local process sniffing the keystrokes and later replaying them. This could be mitigated by having a PAM module permit authentication when a particular SysRq or similar key combination is input. The purpose would be to attest to the fact that the entity requesting privileges is a physical user at the keyboard, not a process.

The threat model

I understand that this is not sufficient for some threat models, but it is for mine. Please consider these below statements to be correct, unless there is a glaring mistake. The threat model is simple:

• Malicious processes want to raise privileges by hijacking the authentication mechanism.
• Only authorized users have physical access. Physical presence alone proves authority.
• Local privilege escalation vulnerabilities that provide root or kernel mode are out-of-scope.
• The input mechanism cannot be compromised, e.g. there is no updatable keyboard firmware.
• Secure Attention Key guarantees that no malicious processes are running in a given TTY.
• Syslog entries cannot be forged. Let's ignore unicode control codes for now.

Authentication with SysRq

As SysRq commands are intercepted by the kernel before they are sent to userspace, and as SysRq commands cannot be injected or forged without physical access (they are designed to only be input through a physical keyboard, ignoring /proc/sysrq-trigger), it seems like certain privileged operations can be safely done without password authentication. The process would look like this:

1. A process (such as su) would need to request privileges. This could be done using a PAM module which checks for a custom SysRq command. Only one command can be requesting privileges at a time. The implementation itself doesn't matter.
2. The system must make the user aware of what command is requesting privileges. Obviously, this must not be possible to spoof, so X11 prompts are right out. A ghetto solution would be logging to the syslog. If the syslog is set to print itself to a particular TTY, the user could switch to that TTY and use Secure Attention Key (SAK). This would ensure that the logs they see are genuine.
3. The user can choose to permit privileges to the command, now that he knows for sure what command is requesting privileges. Entering a particular SysRq command will grant permission.

It seems the idea of using SysRq to enhanced privileges (or more specifically, disable security mechanisms) is not a new idea. The new kernel lockdown functionality can be disabled via SysRq-x.^*

Are there any issues with this proposed authentication mechanism, for my threat model?

_{This is no longer the case, as it appears bypasses exist.}