In context of discussing SysRq it has been raised whether (lesser) adversaries
Should (lesser) Adversaries with Physical Access be part of the Threat Model of Whonix / Whonix-Host / Kicksecure?
Qubes has Anti Evil Maid (AEM).
No because the ability of someone to flash firmware or something less sophisticated like plant physical bugs, would negate even the most elaborate measures. Those who are too simple to pull this off can;t really do much anyhow with an encrypted machine and something simple like a password protected bios.
Pressing a combination on the keyboard is much easier than planting physical bugs or reflashing the firmware.
The adversary we’re talking about here would be someone who’s just an ordinary user and not some expert who can compromise the firmware.
From Kernel Hardening
Alright, let’s assume such an adversary.
Which SysRq command specifically is dangerous here?
Reboot? Probably not. Since such an adversary could just press the power button instead. No gain in using SysRq.
For example, they could kill an important process such as AppArmor or the firewall. They could get a bunch of information about running processes, create crashdumps etc. to analyze certain things for vulnerabilities or look for things stored in RAM like passwords.
These examples aren’t great since apparmor and firewall aren’t processes.
Also I didn’t see a feature to kill any specific process.
To do what? -> Advanced adversary.
To do what? These will end up only accessible by root and on a hopefully encrypted disk?
Disk not encrypted + physical access -> running machine -> game over anyhow.
Disk encrypted + physical access…
I’ve tried all sysrq commands and didn’t see any command to dump RAM contents to console.
Crash dump for RAM contents still requires an active login session. But if we assume physical access + an active login session, then it’s easy to plan malware anyhow.
According to the kernel docs, setting
kernel.sysrq=64 enables signalling of processes so you can send a sigkill to a specific process to kill it.
I meant to say “coredump” when talking about crashdumps. Coredumps contain the recorded memory of a program which can be analysed.
It does seem like the sysrq key isn’t as bad as I originally though it was. I don’t really like having all of those debugging capabilities exposed to anyone with local access though.
I set it it
1 to enable all features. Then see SysRq help (
h). There is no such command to kill specific processes. Made a list here:
Also not found anywhere else online. Only three options:
- ‘i’ – Send the SIGKILL signal to all processes except init
- ‘k’ – Kills all the process running on the current virtual console.
- ‘f’ – Will call oom_kill to kill process which takes more memory.
To analyse you need two things:
- cleverness to actually analyze
-> advanced adversary.