Feature request: Emergency shutdown on USB device unplugging

[Ali Mammadov]

IMHO, It might be good to implement this feature to protect against cold boot attacks and physical stealing of running laptop. Taking in account restrictions on how USB devices are handled in Qubes OS, powering dom0 off by a signal from some VM seems hard to implement, let alone full RAM wipe.

What do you think? Which Qubes OS security mechanisms might prevent this from being implemented?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jun 25, 2016 at 11:19:14AM -0700, Ali Mammadov wrote:
> IMHO, It might be good to implement this feature to protect against cold
> boot attacks and physical stealing of running laptop. Taking in account
> restrictions on how USB devices are handled in Qubes OS, powering dom0 off
> by a signal from some VM seems hard to implement, let alone full RAM wipe.

Actually not that hard. Just a matter of simple qrexec service. This of
course means that malicious USB VM will be able to shutdown your system
at any time...

Take a look here:
https://www.qubes-os.org/doc/qrexec3/

Something like this:

dom0:/etc/qubes-rpc/emergency-shutdown (make it executable)

#!/bin/sh

# some other command to shutdown/wipe ram?
sudo poweroff -fn

dom0:/etc/qubes-rpc/policy/emergency-shutdown

sys-usb dom0 allow
$anyvm $anyvm deny


Then in your sys-usb trigger this command on usb removal:

qrexec-client-vm dom0 emergency-shutdown

It can be done for example with some udev rule:

sys-usb:/rw/config/usb-emergency.rules

ACTION=="remove", ENV{ID_VENDOR}=="1234", ENV{ID_MODEL}=="5678",
RUN+="/usr/bin/qrexec-client-vm dom0 emergency-shutdown"

sys-usb:/rw/config/rc.local (make it executable)

#!/bin/sh

cp /rw/config/usb-emergency.rules /etc/udev/rules.d/
udevadm control --reload


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXbvzxAAoJENuP0xzK19csQosH/jOD7lxIHGzTliMTSxBfW2Ud
tImhZAYI4rcx9feltngkEu95qFwNyxgHDZXmYbs/8NlU+tyVA1BdDFejHC5PNLOb
t6Wea27vtNw/66EQZ2/BiBJtpnNbeM8azwIw9gAJkMhzitAap9lULmLg8TV4rKpB
PTRSS2b7TyowQox6fae2m7A+Hny5wV5X3t37Z0RFf5+JAg7XEkA39+NnTSYaxPOX
ITzeoq6GCQsl+4c/SPmfz3k8Jk4gAMaqnM1LvNrhyXEC8jsIft1rNAQoWUvLfH8S
cS0/ksJwawnq/eDRPVqi5rEfy3LLyhA0It99trss1RXceoAiKc2Z2AnM8cd3ydM=
=w7S+
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Very similar setup is described here for locking screen on YubiKey
removal:
https://www.qubes-os.org/doc/yubi-key/#tocAnchor-1-1-3

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXbv4bAAoJENuP0xzK19csAv8H/ipd8/Biu3eqf+0bRlAKVBLu
9ADxOjEWXtW4+Fle1i0dUtZFtkoGQbNgs1dUCoAtjYeQIr3oewcNUnOdWso30Tdg
8+YJQjO+JecdLqG7iczVDNgGBYWxkXS0Ln1UFa99TTEBe2WBr+E8d0KJpoOxccIW
VtvjimRo/jG+0y/8S2P+F/XFAuqs9lWZR6NrxUBUNrg1ASI5p2HLlrKk565sjLwk
5b6TpUHAbpmhqX4eSaIBMAGVtQOwn8rZQabHzo78CdatmQBR7eMaxZVrCqAIQgBE
BoOLiDRgwMxEuuOHolQsA4a03Z9r0WYcCcjELS1aTm60FZC5Nl342bYC7QqpNeU=
=knWq
-----END PGP SIGNATURE-----

[Ali Mammadov]

Thanks for the scripts. Gonna test 'em soon.
What about wiping the whole RAM?

[Andrew]

Ali Mammadov:

> Thanks for the scripts. Gonna test 'em soon.
> What about wiping the whole RAM?
>

This or something similar has been talked about before.
Marek covered the basics.

Take a look here:
https://groups.google.com/forum/#!topic/qubes-users/oY5fzmXrXlI

And also here:
https://groups.google.com/forum/#!topic/qubes-devel/wHsrkzj3_qI -- this
one also has a crude RAM wiping mechanism.

I think the right way to go is kexec a memory wiping kernel, which
should now be supported by Xen. I don't have time to set it up at the
moment, though.

Andrew