Utilizing Write-Blocked SD Card to Improve Security

[tzwcfq]

@ProfessorManhattan

want to utilize a UHS-II (for slightly faster speeds) SD card to store parts of the OS (and ideally the template VMs, and system VMs) on a write-blocked SD card.

@ProfessorManhattan

I just like the SD card method because my future laptop will have an integrated SD card slot.

It seems that you’re talking about hardware Lock switch on SD card. That switch is not preventing software from writing on SD card, it just says a recommendation for software not to write on it. I’ve written more info here:

Pressing F11 to Access Debian

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 b…

@ProfessorManhattan

Which paths/files should I partition off and store on a write-blocked SD card during the QubesOS installation?

At least protecting boot partition with it makes sense.
Not sure about whole dom0 root on write-protected SD card
Maybe you can just install Qubes on SD card and add secondary storage pool for your non-persistent VMs and then lock SD card from write.

@ProfessorManhattan

If I manage to figure out which parts of the file system can be stored on write-protected media, then how can I prevent Qubes from slowing down?

You can copy dom0 root to the RAM or your SSD and boot from it. You can read about it here:

Qubes in tmpfs

You can use your QubesOS 𝚜𝚝𝚊𝚝𝚎𝚕𝚎𝚜𝚜 just like TailsOS, with persistent storage for VMs. That is pretty simple! It takes 6Gb of extra 𝚁𝙰𝙼 (for store root filesystem files). The steeps: Install QubesOS, boot to it and make base configuration: screen resolution, keyboard layout, etc. Edit kernel parameters variables at grub settings file /etc/default/grub: GRUB_CMDLINE_LINUX="... 𝚛𝚍.𝚋𝚛𝚎𝚊𝚔" GRUB_CMDLINE_XEN_DEFAULT="... dom0_mem=max:10240M ..." The 𝚛𝚍𝚋𝚛𝚎𝚊𝚔 option - drop to a shell at the en…

@ProfessorManhattan

Why isn’t this the way computers work? Shouldn’t system files / libraries / binaries be locked down to prevent malicious substitutes by forcing hardware authentication (in the form of switching the write protection) to modify system files?

Because of usability for average user I guess. You need to update dom0, if you need to add more VMs/persistently change their settings then you need to update dom0 root as well.