sys-PCI storage qube? Error: Non-endpoint PCI devices... And security decrease or increase with appvm secondary storage?

I’d like to use a m-sata disk on the mini-pci-x bus as my backup disk. I’m assuming the drive is compromised so I’d like for it to have it’s own sys-pci qube to keep it away from dom 0.

I tried to assign the pci bus and when starting the qube get the error “Start failed : Internal Error. Non-endpoint PCI devices cannot be assigned to guests.”

As far as I know my PCI have no devices, except that storage drive.

Edit: Still trying to figure out PCI problem above, but this this part of the question is solved but leaving for others.

My chosen solution is manual backups to external drives using rsync further explored here: sys-PCI storage qube? Error: Non-endpoint PCI devices... And security decrease or increase with appvm secondary storage? - #3 by GateOfRanre

Original quesiton:

Mostly for timely backup management and restore in the event of dom 0 compromise, I’ve realized it is probably better to keep qubes-os own it’s own drive or partition, and appvms on it’s own parition / drive. And rather then using qube backup to help me backup my data qube, I’ll connect a drive weekly to that qube and do a folder to folder backup on a separate drive. Or use rsync once I figure it out to just sync the folders with an external drive.

The problem is I cannot leave my computer on for more than 12 hours. A full qubes backup takes longer then this, but copying folder to folder takes much less.

However I’m curious to know if dom 0 can see it’s luk’s boot passphrase? If not, then probably adding a secondary storage might be a security decrease if I have to unlock the drive using the same passphrase while logged into qubes. Or if dom 0 is compromised then it would now know my encryption passphrase of the data drive, which would become a target for AEM cloning or theft.

If it’s the case of dom 0 not knowing it’s passphrase, then it would likely be more secure to just keep my appvms on the same drive and use rsync to a secondary drive if it support the ability to just mirror partitions, or the linux pools or virtual drives that qubes makes automatically, hopefully syncing in encrypted form without needing me to ever type in a passphrase while booted into qubes is possible?

Just to make sure I understand: you are looking to make a backup of certain AppVMs, and this backup is meant to be restored to a new, uncompromised QubesOS system, just in case your current dom0 is compromised? This backup should be encrypted, and your current (possibly compromised dom0) should not be able to know the encryption passphrase of the backup?

If this is the case, I’d remember that if dom0 is compromised, it’s Game Over™. And if dom0 was compromised by an intentional attack, and not some script kid who doesn’t know what they’re doing, then you’d have more problems than figuring out a backup.

For example, couldn’t a compromised dom0 add something malicious to the AppVM data that you back up— making the backup method trivial to worry about?

I don’t know about adding a sys-pci, but if you’re worried about firmware attacks from a compromised drive as well as dom0 sniffing the drive’s encryption passphrase, it might be better to encrypt your AppVM data and then send it over a network to another computer. You could store it in the cloud or rsync it to a home Raspberry Pi or something. Then the drive doesn’t touch dom0 and dom0 can’t know the passphrase.

Yes I’ve decided to just manually mount the qubes partitions on a clean system, in a temp vm using qvm-block attach, then rsync the files, not the appvms out to a third drive, then will just rebuild the appvms on the new qubes system.

About keeping appvms seperate from dom 0, you’re right I was thinking this might add a security benefit, but if dom 0 is compromised, then likely all appvms are compromised as well.

Reading this post, Storage and backup of large amounts of data for ongoing backups in the future I’ve decided I’ll just rsync the files to external drive. It seems the way rsync is made I’ll be able to cancel a backup and resume when time permits without having to recopy already copied files with it’s built in file hash verification. Beyond that I won’t do any sort of RPC in dom 0 for cross qubes communication. And won’t do appvms on secondary storage, instead just backup not for security but in case of drive failure. So for appvm security I’ll just keep documentation on each appvm and the apps installed so I can quickly recreate them anew if compromised.

keep documentation on each appvm and the apps installed so I can quickly recreate them anew if compromised.

apt list --installed | awk -F'/' '{print $1}' is a good place to start.
Also dnf list --installed | awk '{print $1}'.

1 Like

Ah very helpful! Especially with those qubes I’ve setup over many months and can’t even remember what dependencies and such I had to install to get this and that working properly.

I’ve been also meaning to do a comparison of minimal templates with the full templates as well, but didn’t know how, now I do! :slight_smile:

Thanks much!

1 Like