In context of discussing SysRq it has been raised whether (lesser) adversaries
1 Like
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.
2 Likes
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.
1 Like
From Kernel Hardening - security-misc - #180
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.
1 Like
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ā¦
Advanced adversary.
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.
2 Likes
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.
1 Like
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:
- login
- cleverness to actually analyze
ā advanced adversary.
1 Like
We have this wiki page already:
To find a reasonable answer to the original question:
Should (lesser) Adversaries with Physical Access be part of the Threat Model of Whonix / Whonix-Host / Kicksecure?
Answer:
Lesser adversaries capable of pressing well known keys on the keyboard should be unable to compromise the machine such as by circumventing the screensaver.
(Adversaries incapable of deploying self-written firmware trojans, miniature cameras, laser microphones, hardware-based keyloggers, TEMPEST.)
Does that sound reasonable?
Specifically, resolving Screen Locker (In)Security - Can we disable these at least 4 backdoors? seems realistic.
Is SysRq tamed enough currently?
Security discussion summary:
System Recovery using SysRq Key
If not, please summarize/bump here: SysRq (Magic SysRq key)
1 Like
Yes.
1 Like