My computer has two internal SSDs. One has had Debian for a long time. On the other, I installed Qubes last night. It of course broke GRUB, so Qubes would load without asking first as if Debian wasn’t there.
But I could still press F11 at startup to access boot options and select Debian in the BIOS menu. Debian loaded just fine that way.
I understand configuring a dual boot with Qubes presents security risks. But I wonder about the situation I describe above. It’s not technically a dual boot, at least as I understand it. But practically it feels like a dual boot with just one more button to press. Does this situation present security risks for Qubes? Any other considerations for or against doing it the F11 way?
As long as there’s a way besides in dom0 to touch your Qubes’ /boot partition, and to touch your Embedded Controllers, and to touch your BIOS, there are risks presented.
That’s fair. I could set a BIOS/UEFI password, but someone with physical access to the computer could reset it. So is there no reliable way to eliminate these vulnerabilities?
There is actually a workaround for this issue with possibility of modifying /boot partition by malicious software from dual boot OS.
You can write your Qubes /boot partition on SD card and then lock your SD card for write protection.
But not with the Write Protection physical pin that is switched by the slider on the side of SD card but by configuring protection register in SD card.
It is because Write Protection physical pin is only a recommendation for software to not write on the SD card but doesn’t restrict it from doing so. But by configuring protection register the software can’t write on SD card before it configure protection register for writing.
You can access the SD card registers only when it’s configured as MMC block device (/dev/mmcblk*) and can’t access them when device is configured as USB Mass Storage Device (/dev/sd*).
Most USB SD card readers connect over USB and export a Mass Storage Device and can’t access the SD card registers but there are USB SD card readers that connect over USB and export a MMC block device.
So the workaround is:
Buy two SD card readers - one that export a Mass Storage Device and one that export a MMC block device.
Attach your SD card with /boot in the SD card reader that export a Mass Storage Device for daily use.
When you want to update /boot (update initramfs after dom0 update or for something else) then attach your SD card with /boot in the SD card reader that export a Mass Storage Device and unlock it for write protection with sdtool. Remount the /boot and update files on it. Then Lock the SD card write protection with sdtool again and attach your SD card with /boot in the SD card reader that export a Mass Storage Device for daily use.
But it won’t save you from another OS software modifying your hardware firmware.
Of course but at that point, if she wants to boot into debian she might as well unplug the sd entirely which will 100% prevent malicious software from altering it while she’s using the debian partition.
The solution you proposed is relevant if the sd card were to be kept attached at all times, which may not be a remote scenario while logged into qubes. Also consider that mmcblk devices are usually attached to dom0 and if malicious software is able to modify the /boot partition on the sdcard attached to dom0, it means your entire system is already compromised.
But again, write-protection on the sdcard is surely one extra protection.
There is always the human factor and you can forget to unplug the card reader and boot into another OS and it’ll infect the /boot partition on it.
If there is malicious software already in dom0 then your system is already completely compromised and it won’t change anything if it’ll infect /boot partition as well. Or am I missing something?
If you only wanted to mention that my solution won’t help from /boot being infected by already infected dom0 then that’s true. This solution is only protecting /boot from being modified outside of Qubes.
Thank you BEBF738VD and tzwcfq for the thoughts about SD cards. Not sure yet which route I’ll go.
I just had another thought about BIOS/UEFI password protection. While I can’t prevent someone with physical access from resetting it, there are ways to detect when a computer case has been opened. Some stickers or rolls of tape have serial numbers. Alphanumeric would be preferable.
I know two kinds of BIOS/UEFI password protection. One is to boot the computer at all. The other is to change the settings, such as to boot from a USB drive. Tape or stickers with serial numbers would be more helpful in the latter case than in the former case.
If I set a password to boot the computer at all, then one day find it’s no longer prompting for password, it would be pretty obvious there was tampering even without checking the serial number. But if I set a password only for changing BIOS/UEFI settings, the serial number on tape/sticker may be the only way to know someone could have booted from USB. Are my thoughts correct here?
Yes, and someone could physically open the computer and reset the BIOS to remove this restriction. A sticker or strip of tape with a serial number would allow me to detect if the computer had been physically opened. That’s what I was saying above.
It’s not a reliable way of detecting tampering.
Attacker can dump your BIOS firmware with test clip and then flash it back after tampering your /boot partition. So you’ll still get the password prompts from BIOS and the password won’t change but your system will be compromised.
Or he can just remove your hard drive and tamper it with his notebook.