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?

  • So you're happy to require the user to be at the console? – a CVn Jul 28 '19 at 17:36
  • @aCVn Yes. This is about implementing something functionally similar to Windows UAC consent prompts. Linux does not have UIPI, and sysrq is the closest thing that I can think of which proves locality. – forest Jul 29 '19 at 6:32

I like the idea of an added layer of security, though I would say this borders on the whole security through obscurity thing, mainly because you can do sysrq requests from userspace/software (remotely) as I understand it, via /proc/sys/kernel/sysrq and/or /proc/sysrq-trigger. However its not at all a large task to disable these via a sysctl, boot time flag, or via a kernel patch. Without locking this bit down you lose the “must be physically present” requirement. You may need elevated privileges to do sysrq stuff via /proc but i am thinking of a particular situation where you are trying to protect the system from root itself, using something like grsecurity RBAC

If there was a PAM module for it, i would probably use it at least experimentally. Start a GitHub project?

|improve this answer|||||
  • 3
    No, this isn't security through obscurity. While you can indeed trigger sysrq keys through /proc, you must already have root to do so, and are thus already on the other side of the airtight hatchway. – Joseph Sible-Reinstate Monica Jul 28 '19 at 1:32
  • Yes, I stayed that in my post- see “you may need elevated privileges to do sysrq stuff but ...” – adam Jul 28 '19 at 14:54
  • 1
    Even if you are trying to protect the system from root, it still doesn't matter in this case, since the only thing you could do by being root is fake approval for the su/sudo request, which would let you.... be root. – Joseph Sible-Reinstate Monica Jul 28 '19 at 17:21
  • @adam The question specifically states that privilege elevation bugs are out of scope. I've edited the question to be more specific. This is not meant to protect from malicious processes with kernel 0days. – forest Jul 29 '19 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.