mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-12-15 15:59:23 -05:00
resolved merge conflicts
This commit is contained in:
GammaSQ
commit
8f7fb84a1f
105 changed files with 4814 additions and 2016 deletions
|
|
@ -1,20 +1,25 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Emergency Backup Recovery - format version 2
|
||||
title: Emergency Backup Recovery (v2)
|
||||
permalink: /doc/backup-emergency-restore-v2/
|
||||
redirect_from:
|
||||
- /en/doc/backup-emergency-restore-v2/
|
||||
- /doc/BackupEmergencyRestoreV2/
|
||||
---
|
||||
|
||||
Emergency Backup Recovery without Qubes - format version 2
|
||||
==========================================================
|
||||
Emergency Backup Recovery without Qubes (v2)
|
||||
============================================
|
||||
|
||||
This page describes how to perform emergency restore of backup created on Qubes R2 Beta3 or earlier (which uses backup format 2).
|
||||
This page describes how to perform emergency restore of backup created on Qubes
|
||||
R2 Beta3 or earlier (which uses backup format 2).
|
||||
|
||||
The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
|
||||
The Qubes backup system has been designed with emergency disaster recovery in
|
||||
mind. No special Qubes-specific tools are required to access data backed up by
|
||||
Qubes. In the event a Qubes system is unavailable, you can access your data on
|
||||
any GNU/Linux system with the following procedure.
|
||||
|
||||
**Note:** In the following example, the backup file is assumed to be both encrypted and compressed.
|
||||
**Note:** In the following example, the backup file is assumed to be both
|
||||
encrypted and compressed.
|
||||
|
||||
1. Untar the main backup file.
|
||||
|
||||
|
|
@ -36,7 +41,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
dom0-home/dom0user.000.hmac
|
||||
~~~
|
||||
|
||||
1. Verify the integrity of the `private.img` file which houses your data.
|
||||
2. Verify the integrity of the `private.img` file which houses your data.
|
||||
|
||||
~~~
|
||||
[user@restore ~]$ cd vm1/
|
||||
|
|
@ -46,11 +51,15 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
(stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
|
||||
~~~
|
||||
|
||||
**Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error.
|
||||
**Note:** The hash values should match. If they do not match, then the backup
|
||||
file may have been tampered with, or there may have been a storage error.
|
||||
|
||||
**Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`.
|
||||
**Note:** If your backup was hashed with a message digest algorithm other
|
||||
than `sha512`, you must substitute the correct message digest command. A
|
||||
complete list of supported message digest algorithms can be found with
|
||||
`openssl list-message-digest-algorithms`.
|
||||
|
||||
1. Decrypt the `private.img` file.
|
||||
3. Decrypt the `private.img` file.
|
||||
|
||||
~~~
|
||||
[user@restore vm1]$ openssl enc -d -pass pass:your_passphrase -aes-256-cbc -in private.img.000 -out private.img.dec.000
|
||||
|
|
@ -65,18 +74,22 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
done
|
||||
~~~
|
||||
|
||||
**Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`.
|
||||
**Note:** If your backup was encrypted with a cipher algorithm other than
|
||||
`aes-256-cbc`, you must substitute the correct cipher command. A complete
|
||||
list of supported cipher algorithms can be found with `openssl
|
||||
list-cipher-algorithms`.
|
||||
|
||||
1. Decompress the decrypted `private.img` file.
|
||||
4. Decompress the decrypted `private.img` file.
|
||||
|
||||
~~~
|
||||
[user@restore vm1]$ zforce private.img.dec.*
|
||||
[user@restore vm1]$ gunzip private.img.dec.000.gz
|
||||
~~~
|
||||
|
||||
**Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program.
|
||||
**Note:** If your backup was compressed with a program other than `gzip`, you
|
||||
must substitute the correct compression program.
|
||||
|
||||
1. Untar the decrypted and decompressed `private.img` file.
|
||||
5. Untar the decrypted and decompressed `private.img` file.
|
||||
|
||||
~~~
|
||||
[user@restore vm1]$ tar -M -xvf private.img.dec.000
|
||||
|
|
@ -95,9 +108,10 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
~~~
|
||||
|
||||
2. `chmod +x new-volume-script`.
|
||||
3. `tar --new-volume-script=./new-volume-script -xvf private.img.dec.000`. (The `--new-volume-script` option enables multi-volume untaring.)
|
||||
3. `tar --new-volume-script=./new-volume-script -xvf private.img.dec.000`.
|
||||
(The `--new-volume-script` option enables multi-volume untaring.)
|
||||
|
||||
1. Mount the private.img file and access your data.
|
||||
6. Mount the private.img file and access your data.
|
||||
|
||||
~~~
|
||||
[user@restore vm1]$ sudo mkdir /mnt/img
|
||||
|
|
@ -106,6 +120,9 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
This data has been successfully recovered!
|
||||
~~~
|
||||
|
||||
**Note:** You may wish to store a plain text copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. You may obtain a plaintext version of this file in Git repository housing all the documentation at:
|
||||
**Note:** You may wish to store a plain text copy of these instructions with
|
||||
your Qubes backups in the event that you fail to recall the above procedure
|
||||
while this web page is inaccessible. You may obtain a plaintext version of
|
||||
this file in Git repository housing all the documentation at:
|
||||
|
||||
https://github.com/QubesOS/qubes-doc.git
|
||||
|
|
|
|||
|
|
@ -1,20 +1,25 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Emergency Backup Recovery - format version 3
|
||||
title: Emergency Backup Recovery (v3)
|
||||
permalink: /doc/backup-emergency-restore-v3/
|
||||
redirect_from:
|
||||
- /en/doc/backup-emergency-restore-v3/
|
||||
- /doc/BackupEmergencyRestoreV3/
|
||||
---
|
||||
|
||||
Emergency Backup Recovery without Qubes - format version 3
|
||||
==========================================================
|
||||
Emergency Backup Recovery without Qubes (v3)
|
||||
============================================
|
||||
|
||||
This page describes how to perform an emergency restore of a backup created on Qubes R2 or later (which uses backup format version 3).
|
||||
This page describes how to perform an emergency restore of a backup created on
|
||||
Qubes R2 or later (which uses backup format version 3).
|
||||
|
||||
The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
|
||||
The Qubes backup system has been designed with emergency disaster recovery in
|
||||
mind. No special Qubes-specific tools are required to access data backed up by
|
||||
Qubes. In the event a Qubes system is unavailable, you can access your data on
|
||||
any GNU/Linux system with the following procedure.
|
||||
|
||||
**Note:** In the following example, the backup file is both *encrypted* and *compressed*.
|
||||
**Note:** In the following example, the backup file is both *encrypted* and
|
||||
*compressed*.
|
||||
|
||||
1. Untar the main backup file.
|
||||
|
||||
|
|
@ -34,18 +39,28 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
dom0-home/dom0user.000
|
||||
dom0-home/dom0user.000.hmac
|
||||
|
||||
2. Verify the integrity of the `backup-header` file, which contains basic information about your backup.
|
||||
2. Verify the integrity of the `backup-header` file, which contains basic
|
||||
information about your backup.
|
||||
|
||||
[user@restore ~]$ openssl dgst -sha512 -hmac "your_passphrase" backup-header
|
||||
HMAC-SHA512(backup-header)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c
|
||||
[user@restore ~]$ cat backup-header.hmac
|
||||
(stdin)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c
|
||||
|
||||
**Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error.
|
||||
**Note:** The hash values should match. If they do not match, then the
|
||||
backup file may have been tampered with, or there may have been a storage
|
||||
error.
|
||||
|
||||
**Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. This information is contained in the `backup-header` file (see step 3), however it is not recommended to open this file until its integrity and authenticity has been verified (the current step). A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`.
|
||||
**Note:** If your backup was hashed with a message digest algorithm other
|
||||
than `sha512`, you must substitute the correct message digest command. This
|
||||
information is contained in the `backup-header` file (see step 3), however
|
||||
it is not recommended to open this file until its integrity and
|
||||
authenticity has been verified (the current step). A complete list of
|
||||
supported message digest algorithms can be found with `openssl
|
||||
list-message-digest-algorithms`.
|
||||
|
||||
3. Read the `backup-header`. You'll need some of this information later. The file will look similar to this:
|
||||
3. Read the `backup-header`. You'll need some of this information later. The
|
||||
file will look similar to this:
|
||||
|
||||
[user@restore ~]$ cat backup-header
|
||||
version=3
|
||||
|
|
@ -55,7 +70,8 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
compressed=True
|
||||
compression-filter=gzip
|
||||
|
||||
**Note:** If you see `version=2` here, go to [Emergency Backup Recovery - format version 2](/doc/backup-emergency-restore-v2/) instead.
|
||||
**Note:** If you see `version=2` here, go to [Emergency Backup Recovery -
|
||||
format version 2](/doc/backup-emergency-restore-v2/) instead.
|
||||
|
||||
4. Verify the integrity of the `private.img` file which houses your data.
|
||||
|
||||
|
|
@ -65,15 +81,25 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
[user@restore vm1]$ cat private.img.000.hmac
|
||||
(stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
|
||||
|
||||
**Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error.
|
||||
**Note:** The hash values should match. If they do not match, then the
|
||||
backup file may have been tampered with, or there may have been a storage
|
||||
error.
|
||||
|
||||
**Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. This information is contained in the `backup-header` file (see step 3). A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`.
|
||||
**Note:** If your backup was hashed with a message digest algorithm other
|
||||
than `sha512`, you must substitute the correct message digest command. This
|
||||
information is contained in the `backup-header` file (see step 3). A
|
||||
complete list of supported message digest algorithms can be found with
|
||||
`openssl list-message-digest-algorithms`.
|
||||
|
||||
5. Decrypt the `private.img` file.
|
||||
|
||||
[user@restore vm1]$ cat private.img.??? | openssl enc -d -pass pass:your_passphrase -aes-256-cbc -out private.img.dec
|
||||
|
||||
**Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. This information is contained in the `backup-header` file (see step 3). A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`.
|
||||
**Note:** If your backup was encrypted with a cipher algorithm other than
|
||||
`aes-256-cbc`, you must substitute the correct cipher command. This
|
||||
information is contained in the `backup-header` file (see step 3). A
|
||||
complete list of supported cipher algorithms can be found with `openssl
|
||||
list-cipher-algorithms`.
|
||||
|
||||
6. Decompress the decrypted `private.img` file.
|
||||
|
||||
|
|
@ -81,7 +107,13 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
private.img.dec -- replaced with private.img.dec.gz
|
||||
[user@restore vm1]$ gunzip private.img.dec.gz
|
||||
|
||||
**Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program. This information is contained in the `backup-header` file (see step 3).
|
||||
**Note:** If your backup was compressed with a program other than `gzip`,
|
||||
you must substitute the correct compression program. This information is
|
||||
contained in the `backup-header` file (see step 3). For example, if you
|
||||
used `bzip2`, then you should do this:
|
||||
|
||||
[user@restore vm1]$ mv private.img.dec private.img.dec.bz2
|
||||
[user@restore vm1]$ bunzip2 private.img.dec.bz2
|
||||
|
||||
7. Untar the decrypted and decompressed `private.img` file.
|
||||
|
||||
|
|
@ -95,9 +127,14 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
[user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
|
||||
This data has been successfully recovered!
|
||||
|
||||
9. Success! If you wish to recover data from more than one VM in your backup, simply repeat steps 4--8 for each additional VM.
|
||||
9. Success! If you wish to recover data from more than one VM in your backup,
|
||||
simply repeat steps 4--8 for each additional VM.
|
||||
|
||||
**Note:** You may wish to store a copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. All Qubes documentation, including this page, is available in plain text format in the following Git repository:
|
||||
**Note:** You may wish to store a copy of these instructions with your
|
||||
Qubes backups in the event that you fail to recall the above procedure
|
||||
while this web page is inaccessible. All Qubes documentation, including
|
||||
this page, is available in plain text format in the following Git
|
||||
repository:
|
||||
|
||||
https://github.com/QubesOS/qubes-doc.git
|
||||
|
||||
|
|
|
|||
|
|
@ -1,31 +1,84 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Emergency Backup Recovery - format version 4
|
||||
title: Emergency Backup Recovery (v4)
|
||||
permalink: /doc/backup-emergency-restore-v4/
|
||||
redirect_from:
|
||||
- /en/doc/backup-emergency-restore-v4/
|
||||
- /doc/BackupEmergencyRestoreV4/
|
||||
---
|
||||
|
||||
Emergency Backup Recovery without Qubes - format version 4
|
||||
==========================================================
|
||||
Emergency Backup Recovery without Qubes (v4)
|
||||
============================================
|
||||
|
||||
This page describes how to perform an emergency restore of a backup created on Qubes R4.0 or later (which uses backup format version 4).
|
||||
This page describes how to perform an emergency restore of a backup created on
|
||||
Qubes R4.X (which uses backup format version 4).
|
||||
|
||||
The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
|
||||
The Qubes backup system has been designed with emergency disaster recovery in
|
||||
mind. No special Qubes-specific tools are required to access data backed up by
|
||||
Qubes. In the event a Qubes system is unavailable, you can access your data on
|
||||
any GNU/Linux system with the following procedure.
|
||||
|
||||
**Note:** In the following example, the backup file is both *encrypted* and *compressed*.
|
||||
|
||||
1. Backup content is encrypted and integrity protected using [scrypt
|
||||
utility](https://www.tarsnap.com/scrypt.html). You need to obtain it to
|
||||
restore your data. If your distribution have it packaged (like on Debian),
|
||||
install the package standard way, otherwise you need to compile it yourself
|
||||
(verify its signature first!).
|
||||
Versions up to 1.2.0 (inclusive) do not support `-P` option for easier
|
||||
scripting - which means you'll need to enter the passphrase for each file
|
||||
separately, instead of using `echo ... | scrypt`.
|
||||
Required `scrypt` Utility
|
||||
-------------------------
|
||||
|
||||
2. Untar the main backup file.
|
||||
In Qubes 4.X, backups are encrypted and integrity-protected with [scrypt]. You
|
||||
will need a copy of this utility in order to access your data. Since `scrypt`
|
||||
is not pre-installed on every GNU/Linux system, it is strongly recommended that
|
||||
you store a copy of it with your backups. If your distribution has `scrypt`
|
||||
packaged (e.g., Debian), you can install the package in the standard way using
|
||||
your distribution's package manager. Otherwise, you'll need to obtain a
|
||||
compiled binary (instructions below) or compile the program from source
|
||||
yourself. (Don't forget to [verify signatures] first!) Note that versions of
|
||||
`scrypt` up to 1.2.0 (inclusive) do not support the `-P` option for easier
|
||||
scripting, which means you'll need to enter the passphrase for each file
|
||||
separately, instead of using `echo ... | scrypt`.
|
||||
|
||||
Here are instructions for obtaining a compiled `scrypt` binary. This example
|
||||
uses an RPM-based system (Fedora), but the same general procedure should work on
|
||||
any GNU/Linux system.
|
||||
|
||||
1. If you're not on Qubes 4.X, [get and verify the Release 4 Signing Key].
|
||||
2. If you're not on Qubes 4.X, import the Release 4 Signing Key:
|
||||
|
||||
[user@restore ~]$ sudo rpm --import qubes-release-4-signing-key.asc
|
||||
|
||||
3. Download the `scrypt` RPM:
|
||||
|
||||
[user@restore ~]$ dnf download scrypt
|
||||
|
||||
or, if that doesn't work:
|
||||
|
||||
[user@restore ~]$ curl -O https://yum.qubes-os.org/r4.0/current/vm/fc28/rpm/scrypt-1.2.1-1.fc28.x86_64.rpm
|
||||
|
||||
4. Verify the signature on the `scrypt` RPM:
|
||||
|
||||
[user@restore ~]$ rpm -K scrypt-*.rpm
|
||||
scrypt-*.rpm: digests signatures OK
|
||||
|
||||
The message `digests signatures OK` means that both the digest (i.e., the
|
||||
output of a hash function) and PGP signature verification were successful.
|
||||
|
||||
5. Install `rpmdevtools`:
|
||||
|
||||
[user@restore ~]$ sudo dnf install rpmdevtools
|
||||
|
||||
6. Extract the `scrypt` binary from the RPM:
|
||||
|
||||
[user@restore ~]$ rpmdev-extract scrypt-*.rpm
|
||||
|
||||
7. (Optional) Create an alias for the new binary:
|
||||
|
||||
[user@restore ~]$ alias scrypt="scrypt-*/usr/bin/scrypt"
|
||||
|
||||
|
||||
Emergency Recovery Instructions
|
||||
-------------------------------
|
||||
|
||||
**Note:** In the following example, the backup file is both *encrypted* and
|
||||
*compressed*.
|
||||
|
||||
1. Untar the main backup file.
|
||||
|
||||
[user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456
|
||||
backup-header
|
||||
|
|
@ -39,25 +92,35 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
vm1/whitelisted-appmenus.list.000.enc
|
||||
dom0-home/dom0user.000.enc
|
||||
|
||||
3. Set backup passhprase environment variable. While this isn't strictly required, it will be handy later and will avoid saving the passphrase into shell history.
|
||||
**Note:** Each VM in the backup file has its path listed in
|
||||
`qubes.xml.000.enc` (search for the `backup-path` property). You can
|
||||
extract only the files necessary for your VM (`vmX`) with `tar -i -xvf
|
||||
qubes-backup-2015-06-05T123456 backup-header backup-header.hmac vmX/`.
|
||||
|
||||
read backup_pass
|
||||
2. Set the backup passhprase environment variable. While this isn't strictly
|
||||
required, it will be handy later and will avoid saving the passphrase in
|
||||
the shell's history.
|
||||
|
||||
4. Verify integrity of `backup-header`. For compatibility reasons `backup-header.hmac` is in fact is an encrypted *and integrity protected* version of `backup-header`.
|
||||
[user@restore ~]$ read backup_pass
|
||||
|
||||
3. Verify the integrity of `backup-header`. For compatibility reasons,
|
||||
`backup-header.hmac` is an encrypted *and integrity protected*
|
||||
version of `backup-header`.
|
||||
|
||||
[user@restore ~]$ set +H
|
||||
[user@restore ~]$ echo "backup-header!$backup_pass" |\
|
||||
scrypt -P dec backup-header.hmac backup-header.verified && \
|
||||
scrypt dec -P backup-header.hmac backup-header.verified && \
|
||||
diff -qs backup-header backup-header.verified
|
||||
Files backup-header and backup-header.verified are identical
|
||||
|
||||
**Note:** If the above fail, it may be either mean that backup was tampered
|
||||
with, or it is in different format (see point 3 above). In that case, look into
|
||||
`backup-header`, at `version` field. If it contains anything else than
|
||||
`version=4`, go to other version of instruction: [Emergency Backup Recovery -
|
||||
format version 2](/doc/backup-emergency-restore-v2/), [Emergency Backup
|
||||
Recovery - format version 3](/doc/backup-emergency-restore-v3/)
|
||||
**Note:** If this command fails, it may be that the backup was tampered
|
||||
with or is in a different format. In the latter case, look inside
|
||||
`backup-header` at the `version` field. If it contains a value other than
|
||||
`version=4`, go to the instructions for that format version:
|
||||
- [Emergency Backup Recovery without Qubes (v2)]
|
||||
- [Emergency Backup Recovery without Qubes (v3)]
|
||||
|
||||
5. Read the `backup-header`. You'll need some of this information later. The file will look similar to this:
|
||||
4. Read `backup-header`:
|
||||
|
||||
[user@restore ~]$ cat backup-header
|
||||
version=4
|
||||
|
|
@ -65,34 +128,56 @@ Recovery - format version 3](/doc/backup-emergency-restore-v3/)
|
|||
compressed=True
|
||||
compression-filter=gzip
|
||||
backup_id=20161020T123455-1234
|
||||
|
||||
6. Verify the integrity and decrypt the `private.img` file which houses your data.
|
||||
|
||||
[user@restore ~]$ backup_id=20161020T123455-1234 # see backup-header above
|
||||
5. Set `backup_id` to the value in the last line of `backup-header`:
|
||||
|
||||
[user@restore ~]$ backup_id=20161020T123455-1234
|
||||
|
||||
6. Verify the integrity of and decrypt the `private.img` file that houses your
|
||||
data.
|
||||
|
||||
[user@restore ~]$ for f_enc in vm1/private.img.???.enc; do \
|
||||
f_dec=${f_enc%.enc}; \
|
||||
echo "$backup_id!$f_dec!$backup_pass" | scrypt -P dec $f_enc $f_dec || break; \
|
||||
echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc $f_dec || break; \
|
||||
done
|
||||
|
||||
**Note:** If the above fail, most likely your backup is corrupted, or been tampered with.
|
||||
**Note:** If this command fails, it is likely that the backup is corrupted
|
||||
or has been tampered with.
|
||||
|
||||
7. Decompress and untar the decrypted `private.img` file.
|
||||
|
||||
[user@restore ~]$ cat vm1/private.img.??? | gzip -d | tar -xv
|
||||
vm1/private.img
|
||||
|
||||
**Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program. This information is contained in the `backup-header` file (see step 3).
|
||||
**Note:** If your backup was compressed with a program other than `gzip`,
|
||||
you must substitute the correct compression program. This information is
|
||||
contained in `backup-header` (see step 4). For example, if you used `bzip2`,
|
||||
then you should do this:
|
||||
|
||||
8. Mount the private.img file and access your data.
|
||||
[user@restore vm1]$ mv private.img.dec private.img.dec.bz2
|
||||
[user@restore vm1]$ bunzip2 private.img.dec.bz2
|
||||
|
||||
8. Mount `private.img` and access your data.
|
||||
|
||||
[user@restore vm1]$ sudo mkdir /mnt/img
|
||||
[user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
|
||||
[user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
|
||||
This data has been successfully recovered!
|
||||
|
||||
9. Success! If you wish to recover data from more than one VM in your backup, simply repeat steps 5--8 for each additional VM.
|
||||
9. Success! If you wish to recover data from more than one VM in your backup,
|
||||
simply repeat steps 6--8 for each additional VM.
|
||||
|
||||
**Note:** You may wish to store a copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. All Qubes documentation, including this page, is available in plain text format in the following Git repository:
|
||||
**Note:** You may wish to store a copy of these instructions with your
|
||||
Qubes backups in the event that you fail to recall the above procedure
|
||||
while this web page is inaccessible. All Qubes documentation, including
|
||||
this page, is available in plain text format in the following Git
|
||||
repository:
|
||||
|
||||
https://github.com/QubesOS/qubes-doc.git
|
||||
|
||||
[scrypt]: https://www.tarsnap.com/scrypt.html
|
||||
[verify signatures]: https://www.qubes-os.org/security/verifying-signatures)
|
||||
[get and verify the Release 4 Signing Key]: https://www.qubes-os.org/security/verifying-signatures/#2-get-the-release-signing-key
|
||||
[Emergency Backup Recovery without Qubes (v2)]: https://www.qubes-os.org/doc/backup-emergency-restore-v2/
|
||||
[Emergency Backup Recovery without Qubes (v3)]: https://www.qubes-os.org/doc/backup-emergency-restore-v3/
|
||||
|
||||
|
|
|
|||
175
common-tasks/disposablevm.md
Normal file
175
common-tasks/disposablevm.md
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
---
|
||||
layout: doc
|
||||
title: DisposableVMs
|
||||
permalink: /doc/disposablevm/
|
||||
redirect_from:
|
||||
- /doc/dispvm/
|
||||
- /en/doc/dispvm/
|
||||
- /doc/DisposableVms/
|
||||
- /wiki/DisposableVMs/
|
||||
---
|
||||
|
||||
DisposableVMs
|
||||
=============
|
||||
|
||||
A DisposableVM (previously known as a "DispVM") is a lightweight VM that can be created quickly and will disappear when closed.
|
||||
DisposableVMs are usually created in order to host a single application, like a viewer, editor, or web browser.
|
||||
|
||||
From inside an AppVM, choosing the `Open in DisposableVM` option on a file will launch a DisposableVM for just that file.
|
||||
Changes made to a file opened in a DisposableVM are passed back to the originating VM.
|
||||
This means that you can safely work with untrusted files without risk of compromising your other VMs.
|
||||
DisposableVMs can be launched either directly from dom0's Start Menu or terminal window, or from within AppVMs.
|
||||
While running, DisposableVMs will appear in Qubes VM Manager with the name `disp####`.
|
||||
|
||||
See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a DisposableVM.
|
||||
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
If a [DVM Template] becomes compromised, then any DisposableVM based on that DVM Template could be compromised.
|
||||
In particular, the *default* DVM Template is important because it is used by the "Open in DisposableVM" feature.
|
||||
This means that it will have access to everything that you open with this feature.
|
||||
For this reason, it is strongly recommended that you base the default DVM Template on a trusted TemplateVM.
|
||||
|
||||
### DisposableVMs and Local Forensics ###
|
||||
|
||||
At this time, DisposableVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM.
|
||||
For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion).
|
||||
|
||||
When it is essential to avoid leaving any trace, consider using [Tails](https://tails.boum.org/).
|
||||
|
||||
|
||||
DisposableVMs and Networking (R4.0 and later)
|
||||
-----------------------------
|
||||
|
||||
Similarly to how AppVMs are based on their underlying [TemplateVM](https://www.qubes-os.org/doc/glossary/#templatevm), DisposableVMs are based on their underlying [DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).
|
||||
R4.0 introduces the concept of multiple DVM Templates, whereas R3.2 was limited to only one.
|
||||
|
||||
On a fresh installation of Qubes, the default DVM Template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
|
||||
If you have included the Whonix option in your install, there will also be a `whonix-ws-dvm` DVM Template available for your use.
|
||||
|
||||
You can set any AppVM to have the ability to act as a DVM Template with:
|
||||
|
||||
qvm-prefs <vmname> template_for_dispvms True
|
||||
|
||||
The default system wide DVM Template can be changed with `qubes-prefs default_dispvm`.
|
||||
By combining the two, choosing `Open in DisposableVM` from inside an AppVM will open the document in a DisposableVM based on the default DVM Template you specified.
|
||||
|
||||
You can change this behaviour for individual VMs: in the Application Menu, open Qube Settings for the VM in question and go to the "Advanced" tab.
|
||||
Here you can edit the "Default DisposableVM" setting to specify which DVM Template will be used to launch DisposableVMs from that VM.
|
||||
This can also be changed from the command line with:
|
||||
|
||||
qvm-prefs <vmname> default_dispvm <dvmtemplatename>
|
||||
|
||||
For example, `anon-whonix` has been set to use `whonix-ws-dvm` as its `default_dispvm`, instead of the system default.
|
||||
You can even set an AppVM that has also been configured as a DVM Template to use itself, so DisposableVMs launched from within the AppVM/DVM Template would inherit the same settings.
|
||||
|
||||
NetVM and firewall rules for DVM Templates can be set as they can for a normal VM.
|
||||
By default a DisposableVM will inherit the NetVM and firewall settings of the DVM Template on which it is based.
|
||||
This is a change in behaviour from R3.2, where DisposableVMs would inherit the settings of the AppVM from which they were launched.
|
||||
Therefore, launching a DisposableVM from an AppVM will result in it using the network/firewall settings of the DVM Template on which it is based.
|
||||
For example, if an AppVM uses sys-net as its NetVM, but the default system DisposableVM uses sys-whonix, any DisposableVM launched from this AppVM will have sys-whonix as its NetVM.
|
||||
|
||||
**Warning:** The opposite is also true. This means if you have changed anon-whonix's `default_dispvm` to use the system default, and the system default DisposableVM uses sys-net, launching a DisposableVM from inside anon-whonix will result in the DisposableVM using sys-net.
|
||||
|
||||
A DisposableVM launched from the Start Menu inherits the NetVM and firewall settings of the DVM Template on which it is based.
|
||||
Note that changing the "NetVM" setting for the system default DVM Template *does* affect the NetVM of DisposableVMs launched from the Start Menu.
|
||||
Different DVM Templates with individual NetVM settings can be added to the Start Menu.
|
||||
|
||||
**Important Notes:**
|
||||
Some DVM Templates will automatically create a menu item to launch a DVM, if you do not see an entry and want to add one please use the command:
|
||||
|
||||
qvm-features deb-dvm appmenus-dispvm 1
|
||||
|
||||
To launch a DVM from the command line, in dom0 please type the following:
|
||||
|
||||
qvm-run --dispvm=NameOfDVM --service qubes.StartApp+NameOfApp
|
||||
|
||||
|
||||
|
||||
DisposableVMs and Networking (R3.2 and earlier)
|
||||
-----------------------------
|
||||
|
||||
NetVM and firewall rules for DisposableVMs can be set as they can for a normal VM.
|
||||
By default a DisposableVM will inherit the NetVM and firewall settings of the VM from which it is launched.
|
||||
Thus if an AppVM uses sys-net as its NetVM, any DisposableVM launched from this AppVM will also have sys-net as its NetVM.
|
||||
You can change this behaviour for individual VMs: in Qubes VM Manager open VM Settings for the VM in question and go to the "Advanced" tab.
|
||||
Here you can edit the "NetVM for DisposableVM" setting to change the NetVM of any DisposableVM launched from that VM.
|
||||
|
||||
A DisposableVM launched from the Start Menu inherits the NetVM of the [DVM Template](/doc/glossary/#dvm-template).
|
||||
By default the DVM template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
|
||||
As an "internal" VM it is hidden in Qubes VM Manager, but can be shown by selecting "Show/Hide internal VMs".
|
||||
Note that changing the "NetVM for DisposableVM" setting for the DVM Template does *not* affect the NetVM of DisposableVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.
|
||||
|
||||
Opening a file in a DisposableVM via GUI
|
||||
-----------------------------------------
|
||||
|
||||
In an AppVM's file manager, right click on the file you wish to open in a DisposableVM, then choose "Open in DisposableVM".
|
||||
Wait a few seconds and the default application for this file type should appear displaying the file content.
|
||||
This app is running in its own dedicated VM -- a DisposableVM created for the purpose of viewing or editing this very file.
|
||||
Once you close the viewing application the whole DisposableVM will be destroyed.
|
||||
If you have edited the file and saved the changes, the changed file will be saved back to the original AppVM, overwriting the original.
|
||||
|
||||
 
|
||||
|
||||
Opening a fresh web browser instance in a new DisposableVM
|
||||
-----------------------------------------------------------
|
||||
|
||||
Sometimes it is desirable to open an instance of Firefox within a new fresh DisposableVM.
|
||||
This can be done easily using the Start Menu: just go to **Application Menu -\> DisposableVM -\> DisposableVM:Firefox web browser**.
|
||||
Wait a few seconds until a web browser starts.
|
||||
Once you close the viewing application the whole DisposableVM will be destroyed.
|
||||
|
||||
|
||||
|
||||
Opening a file in a DisposableVM via command line (from AppVM)
|
||||
---------------------------------------------------------------
|
||||
|
||||
Use the `qvm-open-in-dvm` command from a terminal in your AppVM:
|
||||
|
||||
~~~
|
||||
[user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf
|
||||
~~~
|
||||
|
||||
Note that the `qvm-open-in-dvm` process will not exit until you close the application in the DisposableVM.
|
||||
|
||||
Starting an arbitrary program in a DisposableVM from an AppVM
|
||||
--------------------------------------------------------------
|
||||
|
||||
Sometimes it can be useful to start an arbitrary program in a DisposableVM. This can be done from an AppVM by running
|
||||
|
||||
~~~
|
||||
[user@vault ~]$ qvm-run '$dispvm' xterm
|
||||
~~~
|
||||
|
||||
The created DisposableVM can be accessed via other tools (such as `qvm-copy-to-vm`) using its `disp####` name as shown in the Qubes Manager or `qvm-ls`.
|
||||
|
||||
Starting an arbitrary application in a DisposableVM via command line (from Dom0)
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
The Start Menu has shortcuts for opening a terminal and a web browser in dedicated DisposableVMs, since these are very common tasks.
|
||||
However, it is possible to start an arbitrary application in a DisposableVM directly from Dom0 by running
|
||||
|
||||
R4.0 (border colour will be inherited from that set in the `dispvm-template`)
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-run --dispvm=dispvm-template --service qubes.StartApp+xterm
|
||||
~~~
|
||||
|
||||
R3.2 (border colour can be specified in the command)
|
||||
~~~
|
||||
[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
|
||||
~~~
|
||||
|
||||
(The DisposableVM appmenu used for starting Firefox runs a very similar command to the one above.)
|
||||
|
||||
Customizing DisposableVMs
|
||||
--------------------------
|
||||
|
||||
You can change the template used to generate the DisposableVMs, and change settings used in the DisposableVM savefile.
|
||||
These changes will be reflected in every new DisposableVM based on that template.
|
||||
Full instructions can be found [here](/doc/disposablevm-customization/).
|
||||
|
||||
|
||||
[DVM Template]: /doc/glossary/#dvm-template
|
||||
|
||||
|
|
@ -1,151 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Disposable VMs
|
||||
permalink: /doc/dispvm/
|
||||
redirect_from:
|
||||
- /en/doc/dispvm/
|
||||
- /doc/DisposableVms/
|
||||
- /wiki/DisposableVMs/
|
||||
---
|
||||
|
||||
Disposable VMs (DispVMs)
|
||||
========================
|
||||
|
||||
A Disposable VM (DispVM) is a lightweight VM that can be created quickly and will disappear when closed.
|
||||
Disposable VMs are usually created in order to host a single application, like a viewer, editor, or web browser.
|
||||
|
||||
From inside an AppVM, choosing the `Open in Disposable VM` option on a file will launch a DispVM for just that file.
|
||||
Changes made to a file opened in a DispVM are passed back to the originating VM.
|
||||
This means that you can safely work with untrusted files without risk of compromising your other VMs.
|
||||
DispVMs can be launched either directly from Dom0's Start Menu or terminal window, or from within AppVMs.
|
||||
While running, DispVMs will appear in Qubes VM Manager with the name `disp####`.
|
||||
|
||||
See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a Disposable VM.
|
||||
|
||||
|
||||
Disposable VMs and Networking (R4.0 and later)
|
||||
-----------------------------
|
||||
|
||||
Similarly to how AppVMs are based on their underlying [TemplateVM](https://www.qubes-os.org/doc/glossary/#templatevm), DispVMs are based on their underlying [DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).
|
||||
R4.0 introduces the concept of multiple DVM Templates, whereas R3.2 was limited to only one.
|
||||
|
||||
On a fresh installation of Qubes, the default DVM Template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
|
||||
If you have included the Whonix option in your install, there will also be a `whonix-ws-dvm` DVM Template available for your use.
|
||||
|
||||
You can set any AppVM to have the ability to act as a DVM Template with:
|
||||
|
||||
qvm-prefs <vmname> template_for_dispvms true
|
||||
|
||||
The default system wide DVM Template can be changed with `qubes-prefs default_dispvm`.
|
||||
By combining the two, choosing `Open in Disposable VM` from inside an AppVM will open the document in a DispVM based on the default DVM Template you specified.
|
||||
|
||||
You can change this behaviour for individual VMs: in the Application Menu, open Qube Settings for the VM in question and go to the "Advanced" tab.
|
||||
Here you can edit the "Default DispVM" setting to specify which DVM Template will be used to launch DispVMs from that VM.
|
||||
This can also be changed from the command line with:
|
||||
|
||||
qvm-prefs <vmname> default_dispvm <dvmtemplatename>
|
||||
|
||||
For example, `anon-whonix` has been set to use `whonix-ws-dvm` as its `default_dispvm`, instead of the system default.
|
||||
You can even set an AppVM that has also been configured as a DVM Template to use itself, so DispVMs launched from within the AppVM/DVM Template would inherit the same settings.
|
||||
|
||||
NetVM and firewall rules for DVM Templates can be set as they can for a normal VM.
|
||||
By default a DispVM will inherit the NetVM and firewall settings of the DVM Template on which it is based.
|
||||
This is a change in behaviour from R3.2, where DispVMs would inherit the settings of the AppVM from which they were launched.
|
||||
Therefore, launching a DispVM from an AppVM will result in it using the network/firewall settings of the DVM Template on which it is based.
|
||||
For example, if an AppVM uses sys-net as its NetVM, but the default system DispVM uses sys-whonix, any DispVM launched from this AppVM will have sys-whonix as its NetVM.
|
||||
|
||||
**Warning:** The opposite is also true. This means if you have changed anon-whonix's `default_dispvm` to use the system default, and the system default DispVM uses sys-net, launching a DispVM from inside anon-whonix will result in the DispVM using sys-net.
|
||||
|
||||
A Disposable VM launched from the Start Menu inherits the NetVM and firewall settings of the DVM Template on which it is based.
|
||||
Note that changing the "NetVM" setting for the system default DVM Template *does* affect the NetVM of DispVMs launched from the Start Menu.
|
||||
Different DVM Templates with individual NetVM settings can be added to the Start Menu.
|
||||
|
||||
Disposable VMs and Networking (R3.2 and earlier)
|
||||
-----------------------------
|
||||
|
||||
NetVM and firewall rules for Disposable VMs can be set as they can for a normal VM.
|
||||
By default a DispVM will inherit the NetVM and firewall settings of the VM from which it is launched.
|
||||
Thus if an AppVM uses sys-net as its NetVM, any DispVM launched from this AppVM will also have sys-net as its NetVM.
|
||||
You can change this behaviour for individual VMs: in Qubes VM Manager open VM Settings for the VM in question and go to the "Advanced" tab.
|
||||
Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.
|
||||
|
||||
A Disposable VM launched from the Start Menu inherits the NetVM of the [DVM Template](/doc/glossary/#dvm-template).
|
||||
By default the DVM template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
|
||||
As an "internal" VM it is hidden in Qubes VM Manager, but can be shown by selecting "Show/Hide internal VMs".
|
||||
Note that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.
|
||||
|
||||
Opening a file in a Disposable VM via GUI
|
||||
-----------------------------------------
|
||||
|
||||
In an AppVM's file manager, right click on the file you wish to open in a Disposable VM, then choose "Open in Disposable VM".
|
||||
Wait a few seconds and the default application for this file type should appear displaying the file content.
|
||||
This app is running in its own dedicated VM -- a Disposable VM created for the purpose of viewing or editing this very file.
|
||||
Once you close the viewing application the whole Disposable VM will be destroyed.
|
||||
If you have edited the file and saved the changes, the changed file will be saved back to the original AppVM, overwriting the original.
|
||||
|
||||
 
|
||||
|
||||
Opening a fresh web browser instance in a new Disposable VM
|
||||
-----------------------------------------------------------
|
||||
|
||||
Sometimes it is desirable to open an instance of Firefox within a new fresh Disposable VM.
|
||||
This can be done easily using the Start Menu: just go to **Application Menu -\> DisposableVM -\> DispVM:Firefox web browser**.
|
||||
Wait a few seconds until a web browser starts.
|
||||
Once you close the viewing application the whole Disposable VM will be destroyed.
|
||||
|
||||
|
||||
|
||||
Opening a file in a Disposable VM via command line (from AppVM)
|
||||
---------------------------------------------------------------
|
||||
|
||||
Use the `qvm-open-in-dvm` command from a terminal in your AppVM:
|
||||
|
||||
~~~
|
||||
[user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf
|
||||
~~~
|
||||
|
||||
Note that the `qvm-open-in-dvm` process will not exit until you close the application in the Disposable VM.
|
||||
|
||||
Starting an arbitrary program in a Disposable VM from an AppVM
|
||||
--------------------------------------------------------------
|
||||
|
||||
Sometimes it can be useful to start an arbitrary program in a DispVM. This can be done from an AppVM by running
|
||||
|
||||
~~~
|
||||
[user@vault ~]$ qvm-run '$dispvm' xterm
|
||||
~~~
|
||||
|
||||
The created Disposable VM can be accessed via other tools (such as `qvm-copy-to-vm`) using its `disp####` name as shown in the Qubes Manager or `qvm-ls`.
|
||||
|
||||
Starting an arbitrary application in a Disposable VM via command line (from Dom0)
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
The Start Menu has shortcuts for opening a terminal and a web browser in dedicated DispVMs, since these are very common tasks.
|
||||
However, it is possible to start an arbitrary application in a DispVM directly from Dom0 by running
|
||||
|
||||
R4.0 (border colour will be inherited from that set in the `dispvm-template`)
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-run --dispvm=dispvm-template --service qubes.StartApp+xterm
|
||||
~~~
|
||||
|
||||
R3.2 (border colour can be specified in the command)
|
||||
~~~
|
||||
[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
|
||||
~~~
|
||||
|
||||
(The Disposable VM appmenu used for starting Firefox runs a very similar command to the one above.)
|
||||
|
||||
Customizing Disposable VMs
|
||||
--------------------------
|
||||
|
||||
You can change the template used to generate the Disposable VMs, and change settings used in the Disposable VM savefile.
|
||||
These changes will be reflected in every new Disposable VM based on that template.
|
||||
Full instructions can be found [here](/doc/dispvm-customization/).
|
||||
|
||||
Disposable VMs and Local Forensics
|
||||
----------------------------------
|
||||
|
||||
At this time, DispVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM.
|
||||
For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion).
|
||||
|
||||
When it is essential to avoid leaving any trace, consider using [Tails](https://tails.boum.org/).
|
||||
|
|
@ -32,16 +32,6 @@ Enabling full screen mode for select VMs
|
|||
|
||||
If you want to enable full screen mode for select VMs, you can do that by creating the following entry in the `/etc/qubes/guid.conf` file in Dom0:
|
||||
|
||||
**Note:** Regardless of the settings below, you can always put a window into
|
||||
fullscreen mode in Xfce4 using the trusted window manager by right-clicking on
|
||||
a window's title bar and selecting "Fullscreen". This functionality should still
|
||||
be considered safe, since a VM window still can't voluntarily enter fullscreen
|
||||
mode. The user must select this option from the trusted window manager in dom0.
|
||||
To exit fullscreen mode from here, press `alt` + `space` to bring up the title
|
||||
bar menu again, then select "Leave Fullscreen".
|
||||
|
||||
**Note:** There should be only one `VM: {}` block in the file (or you will [get into problems](https://groups.google.com/d/msg/qubes-users/-Yf9yNvTsVI/xXsEm8y2lrYJ))
|
||||
|
||||
~~~
|
||||
VM: {
|
||||
personal: {
|
||||
|
|
@ -52,6 +42,8 @@ VM: {
|
|||
|
||||
The string 'personal' above is an example only and should be replaced by the actual name of the VM for which you want to enable this functionality.
|
||||
|
||||
**Note:** There should be only one `VM: {}` block in the file (or you will [get into problems](https://groups.google.com/d/msg/qubes-users/-Yf9yNvTsVI/xXsEm8y2lrYJ))
|
||||
|
||||
One can also enable this functionality for all the VMs globally in the same file, by modifying the 'global' section:
|
||||
|
||||
~~~
|
||||
|
|
@ -66,3 +58,13 @@ global: {
|
|||
~~~
|
||||
|
||||
Be sure to restart the VM(s) after modifying this file, for the changes to take effect.
|
||||
|
||||
|
||||
**Note:** Regardless of the settings above, you can always put a window into
|
||||
fullscreen mode in Xfce4 using the trusted window manager by right-clicking on
|
||||
a window's title bar and selecting "Fullscreen". This functionality should still
|
||||
be considered safe, since a VM window still can't voluntarily enter fullscreen
|
||||
mode. The user must select this option from the trusted window manager in dom0.
|
||||
To exit fullscreen mode from here, press `alt` + `space` to bring up the title
|
||||
bar menu again, then select "Leave Fullscreen".
|
||||
For StandaloneHVMs, you should set the screen resolution in the qube to that of the host, (or larger), *before* setting fullscreen mode in Xfce4.
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ If you only want to create a shortcut for a single AppVM, you can create a custo
|
|||
What about applications in DispVMs?
|
||||
-----------------------------------
|
||||
|
||||
[See here](/doc/dispvm-customization/#adding-arbitrary-programs-to-disposable-vm-application-menu).
|
||||
[See here](/doc/disposablevm-customization/#adding-arbitrary-programs-to-disposablevm-application-menu).
|
||||
|
||||
Behind the scenes
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Updating software in dom0
|
||||
title: Installing and updating software in dom0
|
||||
permalink: /doc/software-update-dom0/
|
||||
redirect_from:
|
||||
- /en/doc/software-update-dom0/
|
||||
|
|
@ -8,47 +8,48 @@ redirect_from:
|
|||
- /wiki/SoftwareUpdateDom0/
|
||||
---
|
||||
|
||||
Updating software in dom0
|
||||
=========================
|
||||
Installing and updating software in dom0
|
||||
========================================
|
||||
|
||||
Why would one want to update software in dom0?
|
||||
----------------------------------------------
|
||||
Why would one want to install or update software in dom0?
|
||||
---------------------------------------------------------
|
||||
|
||||
Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the third-party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan move the disk backends to an untrusted domain in a future Qubes release.) Of course, we believe this software is reasonably secure, and we hope it will not need patching.
|
||||
Normally, there should be few reasons for installing or updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the third-party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan move the disk backends to an untrusted domain in a future Qubes release.) Of course, we believe this software is reasonably secure, and we hope it will not need patching.
|
||||
|
||||
However, we anticipate some other situations in which updating dom0 software might be necessary or desirable:
|
||||
However, we anticipate some other situations in which installing or updating dom0 software might be necessary or desirable:
|
||||
|
||||
- Updating drivers/libs for new hardware support
|
||||
- Correcting non-security related bugs (e.g. new buttons for qubes manager)
|
||||
- Adding new features (e.g. GUI backup tool)
|
||||
|
||||
How is software updated securely in dom0?
|
||||
-----------------------------------------
|
||||
How is software installed and updated securely in dom0?
|
||||
-------------------------------------------------------
|
||||
|
||||
The update process is split into two phases: "resolve and download" and "verify and install." The "resolve and download" phase is handled by the "UpdateVM." (The role of UpdateVM can be assigned to any VM in the Qubes VM Manager, and there are no significant security implications in this choice. By default, this role is assigned to the firewallvm.) After the UpdateVM has successfully downloaded new packages, they are sent to dom0, where they are verified and installed. This separation of duties significantly reduces the attack surface, since all of the network and metadata processing code is removed from the TCB.
|
||||
The install/update process is split into two phases: "resolve and download" and "verify and install." The "resolve and download" phase is handled by the "UpdateVM." (The role of UpdateVM can be assigned to any VM in the Qubes VM Manager, and there are no significant security implications in this choice. By default, this role is assigned to the firewallvm.) After the UpdateVM has successfully downloaded new packages, they are sent to dom0, where they are verified and installed. This separation of duties significantly reduces the attack surface, since all of the network and metadata processing code is removed from the TCB.
|
||||
|
||||
Although this update scheme is far more secure than directly downloading updates in dom0, it is not invulnerable. For example, there is nothing that the Qubes project can feasibly do to prevent a malicious RPM from exploiting a hypothetical bug in GPG's `--verify` operation. At best, we could switch to a different distro or package manager, but any of them could be vulnerable to the same (or a similar) attack. While we could, in theory, write a custom solution, it would only be effective if Qubes repos included all of the regular TemplateVM distro's updates, and this would be far too costly for us to maintain.
|
||||
|
||||
How to update software in dom0
|
||||
------------------------------
|
||||
How to install and update software in dom0
|
||||
------------------------------------------
|
||||
|
||||
As of Qubes R2 Beta 3, the main update functions have been integrated into the Qubes VM Manager GUI: Simply select dom0 in the VM list, then click the **Update VM system** button (the blue, downward-pointing arrow). In addition, updating dom0 has been made more convenient: You will be prompted on the desktop whenever new dom0 updates are available and given the choice to run the update with a single click.
|
||||
### How to update dom0
|
||||
|
||||
Of course, command line tools are still available for accomplishing various update-related tasks (some of which are not available via Qubes VM Manager). In order to update dom0 from the command line, start a console in dom0 and then run one of the following commands:
|
||||
In the Qubes VM Manager, simply select dom0 in the VM list, then click the **Update VM system** button (the blue, downward-pointing arrow). In addition, updating dom0 has been made more convenient: You will be prompted on the desktop whenever new dom0 updates are available and given the choice to run the update with a single click.
|
||||
|
||||
1. To check and install updates for dom0 software:
|
||||
Alternatively, command-line tools are available for accomplishing various update-related tasks (some of which are not available via Qubes VM Manager). In order to update dom0 from the command line, start a console in dom0 and then run one of the following commands:
|
||||
|
||||
To check and install updates for dom0 software:
|
||||
|
||||
~~~
|
||||
$ sudo qubes-dom0-update
|
||||
~~~
|
||||
|
||||
1. To install additional packages in dom0 (usually not recommended):
|
||||
### How to install a specific package
|
||||
|
||||
To install additional packages in dom0 (usually not recommended):
|
||||
|
||||
~~~
|
||||
$ sudo qubes-dom0-update anti-evil-maid
|
||||
~~~
|
||||
|
||||
You may also pass the `--enablerepo=` option in order to enable optional repositories (see yum configuration in dom0). However, this is only for advanced users who really understand what they are doing.
|
||||
You may also pass the `--enablerepo=` option in order to enable optional repositories (see yum configuration in dom0). However, this is only for advanced users who really understand what they are doing.
|
||||
You can also pass commands to `dnf` using `--action=...`.
|
||||
|
||||
### How to downgrade a specific package
|
||||
|
||||
|
|
@ -122,7 +123,7 @@ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
|
|||
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
|
||||
~~~
|
||||
|
||||
To enable or disable any of these repos permanently, change the corresponding boolean in
|
||||
To enable or disable any of these repos permanently, change the corresponding `enabled` value to `1` in
|
||||
`/etc/yum.repos.d/qubes-dom0.repo`.
|
||||
|
||||
### Kernel Upgrade ###
|
||||
|
|
@ -138,9 +139,9 @@ If the update process does not automatically do it (you should see it mentioned
|
|||
from the update command), you may need to manually rebuild the EFI or grub config depending on which
|
||||
your system uses.
|
||||
|
||||
EFI
|
||||
EFI: Replace the example version numbers with the one you are upgrading to.
|
||||
~~~
|
||||
sudo dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)
|
||||
sudo dracut -f /boot/efi/EFI/qubes/initramfs-4.14.35-1.pvops.qubes.x86_64.img 4.14.35-1.pvops.qubes.x86_64
|
||||
~~~
|
||||
|
||||
Grub2
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ sudo dnf upgrade --enablerepo=qubes-vm-*-security-testing
|
|||
sudo dnf upgrade --enablerepo=qubes-vm-*-unstable
|
||||
~~~
|
||||
|
||||
To enable or disable any of these repos permanently, change the corresponding boolean in `/etc/yum.repos.d/qubes-*.repo`.
|
||||
To enable or disable any of these repos permanently, change the corresponding `enabled` value to `1` in `/etc/yum.repos.d/qubes-*.repo`.
|
||||
|
||||
### Debian ###
|
||||
|
||||
|
|
@ -168,7 +168,33 @@ However, a compromise of a template affects only a subset of all your AppVMs (in
|
|||
Also, if your AppVMs are network disconnected, even though their filesystems might get compromised due to the corresponding template compromise, it still would be difficult for the attacker to actually leak out the data stolen in an AppVM.
|
||||
Not impossible (due to existence of cover channels between VMs on x86 architecture), but difficult and slow.
|
||||
|
||||
Standalone VMs
|
||||
|
||||
Standalone VMs (R4.0 and later)
|
||||
--------------
|
||||
Standalone VMs have their own copy of the whole filesystem, and thus can be updated and managed on their own.
|
||||
But this means that they take a few GBs on disk, and also that centralized updates do not apply to them.
|
||||
|
||||
Sometimes it might be convenient to have a VM that has its own filesystem, where you can directly introduce changes, without the need to start/stop the template VM.
|
||||
Such situations include e.g.:
|
||||
|
||||
- VMs used for development (devel environments require a lot of \*-devel packages and specific devel tools)
|
||||
|
||||
- VMs used for installing untrusted packages.
|
||||
Normally you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts).
|
||||
However, when you would like to install some packages from less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way.
|
||||
|
||||
In order to create a standalone VM you can use a command line like this (from console in Dom0):
|
||||
|
||||
```
|
||||
qvm-create --class StandaloneVM --label <label> --property virt_mode=hvm <vmname>
|
||||
```
|
||||
|
||||
... or click appropriate options in the Qubes Manager's Create VM window.
|
||||
|
||||
(Note: Technically, `virt_mode=hvm` is not necessary for every StandaloneVM. However, it makes sense if you want to use a kernel from within the VM.)
|
||||
|
||||
|
||||
Standalone VMs (R3.2 and earlier)
|
||||
--------------
|
||||
|
||||
Standalone VMs have their own copy of the whole filesystem, and thus can be updated and managed on their own.
|
||||
|
|
@ -191,6 +217,7 @@ qvm-create <vmname> --standalone --label <label>
|
|||
|
||||
... or click appropriate options in the Qubes Manager's Create VM window.
|
||||
|
||||
|
||||
Using more than one template
|
||||
----------------------------
|
||||
|
||||
|
|
@ -240,7 +267,7 @@ And in both cases defaults listed above are applied if the service is not explic
|
|||
### Technical details (R4.0)
|
||||
|
||||
Instead of using a network connection like in R3.2, R4.0 uses RPC/qrexec.
|
||||
The proxy is configured in qrexec policy: `/etc/qubes-rpc/policy/qubes.UpdatesProxy`.
|
||||
The proxy is configured in qrexec policy on dom0: `/etc/qubes-rpc/policy/qubes.UpdatesProxy`.
|
||||
By default this is set to sys-net and/or sys-whonix, depending on firstboot choices.
|
||||
This new design allows for templates to be updated even when they are not connected to any netvm.
|
||||
|
||||
|
|
@ -300,7 +327,7 @@ But, of course, the problem of finding malware hooks in general is hard, so this
|
|||
Also note that the user filesystem's metadata might got maliciously modified by malware in order to exploit a hypothetical bug in the AppVM kernel whenever it mounts the malformed filesystem.
|
||||
However, these exploits will automatically stop working (and so the infection might be cleared automatically) after the hypothetical bug got patched and the update applied (via template update), which is an exceptional feature of Qubes OS.
|
||||
|
||||
Also note that Disposable VMs do not have persistent user filesystem, and so they start up completely "clean" every time.
|
||||
Also note that DisposableVMs do not have persistent user filesystem, and so they start up completely "clean" every time.
|
||||
Note the word "clean" means in this context: the same as their template filesystem, of course.
|
||||
|
||||
RPMFusion for a Fedora TemplateVM
|
||||
|
|
|
|||
|
|
@ -144,10 +144,14 @@ If possible, use a method specific for particular device type (for example, bloc
|
|||
### Installation of qubes-usb-proxy ###
|
||||
[installation]: #installation-of-qubes-usb-proxy
|
||||
|
||||
To use this feature, you need to install [`qubes-usb-proxy`][qubes-usb-proxy] package in the templates used for the USB qube and qubes you want to connect USB devices to.
|
||||
Note you cannot pass through devices from dom0 (in other words: USB VM is required).
|
||||
`qubes-usb-proxy` should be installed by default in the template VM.
|
||||
However, if you receive this error: `ERROR: qubes-usb-proxy not installed in the VM`, you can install the `qubes-usb-proxy` with the package manager in the VM you want to attach the USB device to.
|
||||
Note, you cannot pass through devices from dom0 (in other words: a USB VM is required).
|
||||
|
||||
To use this feature, you need to have the [`qubes-usb-proxy`][qubes-usb-proxy] package installed in the template used for the USB qube and in the qube to which you want to connect USB devices. ( If the qube is TemplateBased then it should be installed in the relevant template as usual. )
|
||||
If you do not have the package installed you will see this error: `ERROR: qubes-usb-proxy not installed in the VM`.
|
||||
|
||||
`qubes-usb-proxy` should be installed by default in the standard Fedora and Debian templates.
|
||||
|
||||
You install the `qubes-usb-proxy` package using the package manager as usual.
|
||||
|
||||
- Fedora: `sudo dnf install qubes-usb-proxy`
|
||||
- Debian/Ubuntu: `sudo apt-get install qubes-usb-proxy`
|
||||
|
|
@ -195,4 +199,5 @@ Additional Reading:
|
|||
[usb-challenges]: https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html
|
||||
[YubiKey]: /doc/YubiKey/
|
||||
[Creating a USB qube]: /doc/usb-qube-how-to/
|
||||
[Using a USB keyboard]: /doc/usb-qube-how-to/#enable-a-usb-keyboard-for-login
|
||||
[Using a USB keyboard]: /doc/usb-qube-how-to/#enable-a-usb-keyboard-for-login
|
||||
[qubes-usb-proxy]: https://github.com/QubesOS/qubes-app-linux-usb-proxy
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue