Hi,
I have been wondering how exactly Qubes secures the shutdown and reboot in regards to devices.
Suppose one does something using a USB storage device (in a AppVM or disposable) and detaches the device when the work is done. However, one may forget the USB device plugged in and initiate a reboot.
Then suddenly one sees the device still plugged in just before typing the disk decryption phrase and disconnects the cable.
How does Qubes protect from potential dangers in such cases?
Hi
I’m not entirely sure, but if you use sys-usb without mouse/keyboard allowed by default, there is no USB devices available at boot to type your passphrase. Hope that help answering your question.
Unfortunately, it can’t, which is why it’s a good idea to unplug all such devices before rebooting.
Unfortunately, it can’t
That’s what I suspected. I just wondered if the shutdown process itself is somehow vulnerable. The booting seems OK. Coreboot did not attempt to boot from the USB drive as it is not configured to do that. As usual, I saw the grub menu and was taken to the prompt to type the disk decryption password but I unplugged the device before doing that and rebooted again.
it’s a good idea to unplug all such devices before rebooting.
I know but that evening I was tired and it seems there was an attention blink, so I forgot. Perhaps it would be good to have a feature reminding the user to unplug non-keyboard/mouse before shutdown/reboot?
FWIW, the particular device is a Lexar USB 3.0 flash storage which I have plugged only in my own Linux computers and TVs. Used mainly for media storage/playback.
Although I don’t expect any danger, I wonder if there is any way for one to check.
How about Ethernet? Any benefits in unplugging internet cable every time before shutdown and plug-in after QubesOS boots or it isn’t worth the hassle?
At least, it can protect against a power surge from a storm.
Seems worthy of consideration. Please feel free to open an enhancement request for this if one doesn’t already exist.
I seem to recall being told that the risk with an ethernet cable is miniscule compared to something like USB, but since I’m already unplugging a bunch of other stuff anyway, I just unplug the ethernet cable too. 
I seem to recall being told that the risk with an ethernet cable is miniscule compared to something like USB, but since I’m already unplugging a bunch of other stuff anyway, I just unplug the ethernet cable too.
What exact threat does that protect from?
Can you explain?
Why is this dangerous?
I don’t remember exactly. All I remember is asking @marmarek about it some time ago and this being the gist of the answer.
My basic understanding is that a malicious device that remains plugged in could attack the system during (re)boot, because the usual protections Qubes OS provides (e.g., isolating risky devices in VMs) are not available before Qubes is running.
@marmarek or @Demi may be able to provide a better explanation.
@marmarek or @Demi may be able to provide a better explanation.
I would be really interested to know that before breaking down the Ethernet port (or adding extra intermediary connectors to worsen the network throughput).
I can guess that this could prevent malicious PXE boot.
It all very much depends on firmware (aka UEFI / BIOS) in given system. Most have option to enable/disable network booting (in fact, network boot is usually disabled by default). Some have an option to disable USB boot or even using USB at all. Disabling those parts in firmware settings should mitigate most risks related to having external devices plugged in during (re)boot.
I can guess that this could prevent malicious PXE boot.
Is PXE boot possible with coreboot?
Network boot is supported by coreboot:
https://www.coreboot.org/Payloads#Etherboot_/_GPXE_/_iPXE
How about during shutdown?
AFAIK Heads should protect you even if you forgot to remove a USB device. It verifies that coreboot, /boot and /root are intact every time.
After sys-net/sys-usb shutdown relevant devices remain isolated (they are not transferred to dom0) so no problem there.
Thanks @marmarek.