can I use paranoid mode from a 3.2 backup?

65 views
Skip to first unread message

cooloutac

unread,
Dec 20, 2017, 1:35:26 PM12/20/17
to qubes-users
Thinking of upgrading to 4.0.
if I want to restore vms from 3.2, possibly compromised, system. Can I use the paranoid restore mode in 4.0, or would that only work from 4.0 backup.

Tks in advance.

rich.

Yuraeitha

unread,
Dec 21, 2017, 10:08:01 AM12/21/17
to qubes-users

It's my understanding that this is not only preferred, but also a really good idea, when moving to a new upgraded base system (3.2 ---> 4.0). But I'm no expert either.

The reasoning being that no data should be kept in dom0 anyway, so the only thing you loose is stuff like your XFCE4 configurations (or other dom0 system settings), and possibly screenshots you took (which currently are still saved to dom0). Stuff like that.

So by using paranoid mode, you only backup the AppVM's and Template VM's, without any base settings or dom0 files, (iirc). But even your Template VM's are redundant and can easily be re-installed on a new system. It might be a good idea to to not restore any templates either, because the code is in all liklihood different in Qubes 3.2. templates, compared to Qubes 4.0 VM-Templates. Moreover, if your dom0 was compromised, then your tempaltes were probably also compromised anyway.

So that's two reasons not to inklude dom0, templates or base settings, and only restore the AppVM's, due to not only security but also reliability. However, what I normally do, is just backup everything, pretty much dom0, any tempalteVM's, all AppVM's, everything. Then I put the backup at absolutely minimum 2 different places, and run an integrity check to ensure the backup is whole.

Once that is done, I only restore the AppVM's that I still need. If I ever unexpectedly need something else, then I still got the full backup laying around.

It's true that the backup-restore could be compromised as well, and reading the backup file from a compromised Qubes system could thereby exploit faults in the qvm-backup-restore. However, the odds for that is quite remote. For one, it probably would only happen to high profile targets, as it would require a targeted, and probably resourceful/costly attack. There is a big difference between automated, semi-automated, and targeting attacks. There is, imho, very low odds that any automated or semi-automated attacks even exist, and the code is so small and clean, that it's likely anyway.

At least in todays time, I wouldn't worry. If you just make a full backup, and ensure the integrity, then you should be okay. Even if Qubes 4 does not work for you, you can always fall back to Qubes 3.2. But keep in mind that Qubes 4 is still in testing phase, and some basic things are not fully working yet. To my understanding, it'll only come out of testing phase and become a final release, once it becomes certain that normal updates can fix any issues.

Also take note, that there currently is no graphic interface to backup and backup restore in Qubes 4.0. It'd be a good idea to practice in the 3.2. terminal before switching, so you know you can do it in Qubes 4.0.
If you want to exclude (-x) Templates, dom0, and some of the AppVM's, then you need to run several "-x AppVM-9 -x Template-5 -x AppVM-1" arguments, in the backup restore line. The order does not matter. You can run qvm-backup-restore first without the exlusions, to get a print of all the VM's, then type ctrl+c to break back to terminal, and write all the -x VM arguments you need onto the qvm-backup-restore command.

Also take note, you should avoid doing backup restore or backup create in dom0 in Qubes 4, as the code here apparently has changed since Qubes 3.2. I have no idea if its safe, but it's apparently slower to do it in dom0. You need a " -d AppVM (destination), for both backup restore, or backup create, followed by a pathline inside that AppVM.

Running qvm-backup -h and qvm-backup-restore -h will give you helpful information. Further using "man qvm-backup" and "man qvm-backup-restore" should give you the manuals.

Hopefully everything works out for you, just make sure to ensure redundancy, in case something goes wrong, and you can fall back to Qubes 3.2. Also to take note, Qubes 4 isn't ready for release or productivity yet.

Marek Marczykowski-Górecki

unread,
Dec 23, 2017, 8:40:08 PM12/23/17
to cooloutac, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 20, 2017 at 10:35:26AM -0800, cooloutac wrote:
> Thinking of upgrading to 4.0.
> if I want to restore vms from 3.2, possibly compromised, system. Can I use the paranoid restore mode in 4.0, or would that only work from 4.0 backup.

This isn't properly documented yet. The general idea is to restore the
backup using some dedicated VM (maybe even disposable VM), instead of
dom0. See here: https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/#sandboxed-paranoid-backup-restores
In the section "Simple management VM demo", you can find required steps
to setup qrexec policy to allow such operation.

Our previous tests weren't very successful:
https://github.com/QubesOS/qubes-issues/issues/2986

But things have improved since then and hopefully(*) it works now.

(*) which reminds me to add automated test for this case of backup
too...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlo/BXEACgkQ24/THMrX
1yzWLAf+M3aaE2f654BE0K1GKeMQvKn9Aj2ZeWeGQJGyWSY2Or2yP56mqQ83sb71
Pl/fdV0f+PX2PkZbvezHawni+kuTLJ7I7B6njrfbOZvjNNozP/P8e9AuRRa4G9Jw
RgNY88BF5UmOU/ZK6RnDeLi9DSiQZI1olNmsNn3emrvu6Y2gilt0vmxCAa7mfKYd
7sk/Xt0oyH/q260kZwdNysu66gULnq1x3lwtGrhpWD0Zui/StKZ56yHicX5liau+
foap465e1gwhtuIkO50KAqAZHYrWWmh1yMUeoqfouUDBe0wYZ1MPyzSTEILkKsYx
3NasV/1rPOhGNnPMkFKRy+FNyK2RQQ==
=ty+y
-----END PGP SIGNATURE-----

cooloutac

unread,
Dec 26, 2017, 9:32:29 AM12/26/17
to qubes-users
tks when I get a chance I'll give it a shot.
Reply all
Reply to author
Forward
0 new messages