Implementing sys-usb Post-Installation?

[Qasker123]

Hi , during installation, the option to create sys-sub was disabled. I think because I chose to store /boot and /boot/efi on a USB stick

I followed this thread but just for taking the boot partiiotn out ( not the LUKS header )

Install Qubes OS with boot partition and a detached LUKS header on USB

The purpose of having a detached LUKS header and boot partition on a separate external disk is to achieve a deniable encryption: Deniable encryption - Wikipedia The encrypted disk will look like an unused/empty unpartitioned disk. Boot into Qubes OS installer and on GUI screen switch to shell on another TTY by pressing Ctrl+Alt+F2. Assuming: /dev/sda - disk where you want to install Qubes OS /dev/sdb - USB disk where you want to install Qubes OS boot partition Find out the right disk name…

Now I want to implement sys-usb manually.
My worry is that because my /boot and /boot/efi is stored on a USB stick which will be connected to the USB port, after I implement the sys-sub and attach the USB controller ( on which my usb stick will be ) to sys-usb rather than dom0, I will have issue booting to my system.

I am new from Windows and already struggling a bit, I dont wan to break my system. Other than audio, my OS is working fine.

[Qasker123]

Reporting Back
I could create a sys-usb Qube post installation using the command given in the documentation . All my USB controllers got automatically assigned to sys-usb. The USB stick that I boot the Qubes from also now get attached to sys-usb. This is considered resolved.

[weird_pci]

However do note that if your boot is on this USB device you won’t be able to update your kernel.

The unencrypted boot partition contains Grub, Xen, Kernel and initrd for kernel(afaik).

Updating any of those inside Dom0 would fail if the USB device is not inside Dom0.

If in doubt, do lsblk and df in Dom0.
If you don’t see the it the partition there, you would have problems.

For this to work correctly, you’d need to reattach the USB device back to Dom0 whenever you update. A clean solution would be having multiple USB controllers and keeping one in Dom0 to host this boot device.

Any other solution would come with more complexity.

One way you could hack around it is to actually make such folders in /. Then on every update you can manually sync the files pushing them from dom0 to sys-usb.

Warning!
Do note however what you right now have also kinda obsoletes the idea of sys-usb.

Having the kernel and xen executables there means anything compromising your sys-usb would be able to modify your kernel and on reboot your system would be compromised.

If you want to keep this setup, perhaps, unplug your device after Qubes loads. That’s not a guarantee but it’s better than keeping it in.

[Qasker123]

The poster of the original link from where I borrowed this idea, did tell about the need of the / boot and /boot/EFI portions attached and mounted on dom0 before updating dom0.
Before I implemented sys-usb manually, my usb stick was attached to dom0 and I just mounted it and then I could update dom0 so it does work.
Thanks for your inputs.
Regarding your last part about chances of my usb stick getting corrupted by sys-usb, does keeping a backup mitigate the risk? I climbed it using dd command and I can boot from the cloned copy.
I am.a regular guy coming from Windows . Don’t understand it much. Trying to learn as I go. I did this setup because I wanted to dual boot my laptop along with Windows but wanted to keep boot files separate from the laptop to avoid conflict with Windows.

[weird_pci]

Of course you should backup your boot USB. I’d buy 1-2 more USB sticks and clone it(small cheap ones).
That being said you will need to sync them whenever you update one.

Now the risk comes from other USB devices connected to sys-usb. Assuming you boot your computer with other stuff plugged in USB ports connected to USB controllers serviced by sys-usb, it means they would technically be able to compromise your USB drive if it’s also plugged in a USB controller that’s in sys-usb.

Whether that would happen depends a lot on the type of USB devices. A simple mouse or keyboard would hardly have the ability to hack you(unless a dedicated attacker made it on purpose and somehow gave it to you).

Ideally your keyboard and mouse should be PS2 and not USB. If not possible, then it’s best to have 2 USB controllers and have the keyboard/mouse one in Dom0.

Anyhow, assuming you plug other devices in there, like an Android phone, risks get compounded since a phone can be compromised.

If you can always boot clean(no USB devices in sys-usb) other than your USB boot drive. And then unplug the USB boot drive afterwards. That would be ideal.

This way you’re not exposing it.

Your threat model changes a lot on whether it’s a laptop or a desktop.

But I think if you’re worried about someone tampering your computer’s disk, using just a boot USB drive won’t be enough. Look into Anti-Evil Maid.

I’d say you can’t really protect your system against attackers with physical access. There’s always ways.

One way would be for an attacker to put a new EFI partition that would load something malicious before booting from the EFI on your USB drive.

Ideally if you have a BIOS password, you can at least prevent modification of BIOS settings so that whoever wants to do it, has to reset things. And you’d know because your computer won’t ask for a password when you turn it on.

Anyhow, advice can only be based on your threat model:
Laptop or Desktop?
Physically accessible to attackers?
Keyboard/Mouse via PS2 or USB?
More than 1 USB controller or not?
What type of devices are plugged in USB on start?
etc.

Meanwhile to harden it, put BIOS user/admin passwords and look into usbguard.
Also check Anti-Evil maid.