I want to discuss some of the security implications when dual-booting Linux and Windows and how to reduce vectors from which Windows could compromise a Linux install.
The most obvious step is to encrypt the Linux installation but that leaves the boot partition vulnerable to manipulation which I think is standard with most Linux installs, I understand that this can also be encrypted but will still be vulnerable to attacks like Evil Maid, which in turn can be mitigated by using custom keys (described here) for secure boot but that would probably not be feasible with dual-booting Windows.
I believe one option is to keep the Linux boot and efi partitions on a USB-drive and just unplug that when the computer boots into Windows.
I was however wondering if using an disk password in the UEFI on top of Linux encryption might work, assuming the computer could boot without the HDD password being provided and just make that drive inaccessible? Back when ATA was a thing you could disable drives in BIOS and make them inaccessible to the OS but such features are mostly gone afaik.
Anyway, looking for a sanity check and to hear what steps people have taken to reduce the risk of Windows compromising a Linux install?
It really comes down to what you’re most concerned about. Secure Boot will prevent your system from booting if your linux bootloader is modified by malware and is sufficient for most use cases. But physical access attacks will always be difficult to defend against. It would be trivial to clear CMOS, disable Secure Boot, and then install an unsigned bootloader. Or at that point I guess they could just import their own key and leave Secure Boot enabled.
Correct. Since you need Microsoft’s key to dual boot, using a custom key is sort of pointless.
Take a look at Kanguru FlashTrust USB drives if you go this route. It has a physical write-protect switch and protects against badUSB by requiring signed firmware updates.
I know my 2019 Dell Insprion still supports passwords on M.2 SATA drives. If your motherboard has support, this could be another method to protect your boot partition from Evil maid attacks. Won’t affect system performance if you only use the drive for EFI and boot.
And if you’re going to this much trouble to prevent physical attacks I’d also set a UEFI user password. This way you’ll know if someone has cleared CMOS when you don’t get a password prompt.
in my admittedly old school experience of hacking a computer…
the hack would have to stay memory resident during reset, start itself after the eufi, then read the grub, figure out what version of linux your running, deploy an exploit for that version and then dial home.
all without user input.
sounds do-able. the way i just rattled it off… but theres one flaw.
the flaw?.
i would need access to the second system, to issue the command to run the hack.
why?.
once the system restarts the program goes dormant in memory and needs a trigger to be sent to wake it.
now a clever hacker might be able to put something in the tpm module. in such a way as when the system starts, reads the tpm module and triggers a call that starts the mem resident hack.
but…
thats pure hypothetical as im not sure the tpm module is allowed to execute code.
the other way, linux would already have to be externally compromised to get the shell to run the user call to memory to start the program. but still he would have to compromise windows in the same way i mentioned earlier, then wait for you to reboot into linux. and then compromise that system, negating the need for the mem resident hack in the first place.
so yeah one way needs the leetest of the leet, the other a script kiddy with a hardon for your servers.
the latter i would be more worried about to be honest.
they may take your data but even winrar will take years to crack if you us a 10+ asc/dec pin code to lock the archives.
so i would just lock them up than trying to lock the system down for what really is a hypothetical scenario.
(psst i once or twice wrote mem resident hacks, i found i couldnt get an exploit after the switch to 32bit due to the way memory is allocated and protected by nt system)
