Should (lesser) Adversaries with Physical Access be part of the Threat Model of Whonix / Whonix-Host / Kicksecure?

In context of discussing SysRq it has been raised whether (lesser) adversaries

1 Like

Qubes has Anti Evil Maid (AEM).



Protection against Physical Attacks


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