Proper "paranoid mode" backup restore using DisposableVM #5310

marmarek · 2019-09-10T13:41:03Z

The problem you're addressing (if any)
Ease restoring backup using DisposableVM and Admin API. Context: https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/

Describe the solution you'd like
It's already possible to restore using DisposableVM, but the process is manual. Especially setting qrexec policy is non-trivial.

Where is the value to a user, and who might that user be?
Easier safe data migration from potentially compromised machine.

Additional context
This is follow up work for QSB #51

Add pair of services: 1. qubes.RegisterBackupLocation - called by dom0, registers what backup location (including both file and command options) can be accessed. Registered location gets an ID returned to the caller. The location (and its ID) is valid as long as the service call remains open. 2. qubes.RestoreById - called by restoring DispVM to retrieve the backup content. The service expects location ID as an argument, and then list of files/directories (separated with spaces) on the first line of stdin. This is very similar to qubes.Restore service, with exception for the archive location control. QubesOS/qubes-issues#5310

Getting name of QubesVM object doesn't require Admin API call that could be not allowed by this VM QubesOS/qubes-issues#5310

Allow setting alternative qrexec service to retrieve backup content. The service API is slightly different than the default one: it will get only list of files/directories to extract on its stdin, but not backup location. The latter could be provided as a service argument, or using other out-of-band mechanism. This will be useful for paranoid backup restore mode, to take away control over location/command from sandboxed qvm-backup-restore process. QubesOS/qubes-issues#5310

…ring Make it possible to use qvm-backup-restore in a VM. This commit is about accessing backup itself, when stored in another VM. This involve using qfile-unpacker instead of qfile-dom0-unpacker and also requesting disk space monitoring, as a VM probably won't have enough space to hold the whole backup at once. QubesOS/qubes-issues#4791 QubesOS/qubes-issues#5310

Needed to extrac backup archive QubesOS/qubes-issues#5310

Having Admin API, it is possible to do this properly now: - create DisposableVM - assign it proper permissions to create VMs and control those created VMs - run restore process inside - cleanup DisposableVM afterwards This feature depends on modifications in various other components, including: - linux-utils and core-agent-linux for update qfile-unpacker - core-admin for qrexec policy modification QubesOS/qubes-issues#5310

…files This will be useful for "paranoid mode" backup restore policy. QubesOS/qubes-issues#5310

When a VM with 'tag-created-vm-with' feature set creates a VM (using Admin API), that VM will get all the tags listed in the feature. Multiple tags can be separated with spaces. This will be useful to tag VMs created during paranoid mode backup restore. QubesOS/qubes-issues#5310

Do not allow starting a VM while the restoring management VM has still control over it. Specifically, that restoring VM will not be able to start just restored VM. QubesOS/qubes-issues#5310

Policy allows a VM with 'backup-restore-mgmt' tag to create VMs, and then manage VMs with 'backup-restore-in-progress' tag (which is added by AdminExtension, based on 'tag-created-vm-with' feature). VM with 'backup-restore-mgmt' tag can also call qubes.RestoreById service to a VM with 'backup-restore-storage' tag. This service allows to retrieve backup archive. QubesOS/qubes-issues#5310