mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Mass replace "AppVM" and "TemplateBasedVM" with "app qube"
QubesOS/qubes-issues#1015
This commit is contained in:
Andrew David Wong
parent
719836c9f3
commit
aea595397f
@ -12,12 +12,12 @@ title: How to Make Any File Persistent (bind-dirs)
|
||||
## What are bind-dirs? ##
|
||||
|
||||
With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
|
||||
any arbitrary files or folders can be made persistent in TemplateBasedVMs.
|
||||
any arbitrary files or folders can be made persistent in app qubes.
|
||||
|
||||
## What is it useful for? ##
|
||||
|
||||
In a TemplateBasedVM all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`.
|
||||
This means that changes in the rest of the filesystem are lost when the TemplateBasedVM is shutdown.
|
||||
In an app qube all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`.
|
||||
This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
|
||||
bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
|
||||
|
||||
For example, in Whonix, [Tor's data dir `/var/lib/tor` has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5)
|
||||
@ -27,7 +27,7 @@ In this way sys-whonix can benefit from the Tor anonymity feature 'persistent To
|
||||
|
||||
In this example, we want to make `/var/lib/tor` persistent.
|
||||
|
||||
Inside the TemplateBasedVM.
|
||||
Inside the app qube.
|
||||
|
||||
1. Make sure folder `/rw/config/qubes-bind-dirs.d` exists.
|
||||
|
||||
@ -45,7 +45,7 @@ Inside the TemplateBasedVM.
|
||||
|
||||
4. Save.
|
||||
|
||||
5. Reboot the TemplateBasedVM.
|
||||
5. Reboot the app qube.
|
||||
|
||||
6. Done.
|
||||
|
||||
@ -67,17 +67,17 @@ binds+=( '/etc/tor/torrc' )
|
||||
|
||||
## How does it work? ##
|
||||
|
||||
bind-dirs.sh is called at startup of a TemplateBasedVM, and configuration files in the above configuration folders are parsed to build a bash array.
|
||||
bind-dirs.sh is called at startup of an app qube, and configuration files in the above configuration folders are parsed to build a bash array.
|
||||
Files or folders identified in the array are copied to `/rw/bind-dirs` if they do not already exist there, and are then bind mounted over the original files/folders.
|
||||
|
||||
Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the TemplateBasedVM is restarted after configuration.
|
||||
Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the app qube is restarted after configuration.
|
||||
|
||||
If you want to circumvent this process, you can create the relevant file structure under `/rw/bind-dirs` and make any changes at the same time that you perform the configuration, before reboot.
|
||||
Note that you must create the full folder structure under `/rw/bind-dirs` - e.g you would have to create `/rw/bind-dirs/var/lib/tor`
|
||||
|
||||
## Limitations ##
|
||||
|
||||
* Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh.
|
||||
* Files that exist in the TemplateVM root image cannot be deleted in the app qubes root image using bind-dirs.sh.
|
||||
* Re-running `sudo /usr/lib/qubes/init/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/init/bind-dirs.sh umount` does not work.
|
||||
* Running `sudo /usr/lib/qubes/init/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that.
|
||||
* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.
|
||||
@ -102,5 +102,5 @@ binds=( "${binds[@]/'/var/lib/tor'}" )
|
||||
|
||||
## Discussion ##
|
||||
|
||||
[TemplateBasedVMs: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion)
|
||||
[app qubes: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion)
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ The scripts here all run as root.
|
||||
|
||||
- `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change.
|
||||
|
||||
- In ProxyVMs (or AppVMs with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up.
|
||||
- In ProxyVMs (or app qubes with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up.
|
||||
Good place to write custom firewall rules.
|
||||
|
||||
~~~
|
||||
@ -49,7 +49,7 @@ The scripts here all run as root.
|
||||
The file is used only in a VM with PCI devices attached.
|
||||
Intended for use with problematic device drivers.
|
||||
|
||||
- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV AppVM `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`:
|
||||
- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV app qube `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`:
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
@ -75,7 +75,7 @@ The scripts here all run as root.
|
||||
|
||||
Note that scripts need to be executable (`chmod +x`) to be used.
|
||||
|
||||
Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an AppVM and have those changes persist.
|
||||
Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an app qube and have those changes persist.
|
||||
|
||||
GUI and audio configuration in dom0
|
||||
-----------------------------------
|
||||
|
||||
@ -15,15 +15,15 @@ title: DisposableVM Customization
|
||||
|
||||
## Introduction
|
||||
|
||||
A [DisposableVM](/doc/disposablevm) can be based on any [TemplateBasedVM](/doc/glossary/#templatebasedvm).
|
||||
A [DisposableVM](/doc/disposablevm) can be based on any [app qube](/doc/glossary/#app-qube).
|
||||
You can also choose to use different [DisposableVM Templates](/doc/glossary/#disposablevm-template) for different DisposableVMs.
|
||||
To prepare an AppVM to be a DisposableVM Template, you need to set `template_for_dispvms` property, for example:
|
||||
To prepare an app qube to be a DisposableVM Template, you need to set `template_for_dispvms` property, for example:
|
||||
|
||||
```shell_session
|
||||
[user@dom0 ~]$ qvm-prefs fedora-26-dvm template_for_dispvms True
|
||||
```
|
||||
|
||||
Additionally, if you want to have menu entries for starting applications in DisposableVM based on this AppVM (instead of in the AppVM itself), you can achieve it with `appmenus-dispvm` feature:
|
||||
Additionally, if you want to have menu entries for starting applications in DisposableVM based on this app qube (instead of in the app qube itself), you can achieve it with `appmenus-dispvm` feature:
|
||||
|
||||
```shell_session
|
||||
[user@dom0 ~]$ qvm-features fedora-26-dvm appmenus-dispvm 1
|
||||
@ -84,8 +84,8 @@ This can be done by customizing the DisposableVM Template on which it is based:
|
||||
|
||||
You can use a static DisposableVM for `sys-*` as long as it is stateless.
|
||||
For example, a `sys-net` using DHCP or `sys-usb` will work.
|
||||
In most cases `sys-firewall` will also work, even if you have configured AppVM firewall rules.
|
||||
The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall AppVM.
|
||||
In most cases `sys-firewall` will also work, even if you have configured app qube firewall rules.
|
||||
The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall app qube.
|
||||
|
||||
To create one that has no PCI devices attached, such as for `sys-firewall`:
|
||||
|
||||
@ -141,7 +141,7 @@ qubes-prefs clockvm sys-net2
|
||||
|
||||
For added convenience, arbitrary programs can be added to the Application Menu of the DisposableVM.
|
||||
|
||||
In order to do that, select "Qube settings" entry in selected base AppVM, go to "Applications" tab and select desired applications as for any other qube.
|
||||
In order to do that, select "Qube settings" entry in selected base app qube, go to "Applications" tab and select desired applications as for any other qube.
|
||||
|
||||
Note that currently only applications whose main process keeps running until you close the application (i.e. do not start a background process instead) will work. One of known examples of incompatible applications is GNOME Terminal (shown on the list as "Terminal"). Choose different terminal emulator (like XTerm) instead.
|
||||
|
||||
@ -255,7 +255,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe
|
||||
[user@dom0 ~]$ qvm-prefs disp-sys-firewall netvm disp-sys-net
|
||||
```
|
||||
|
||||
4. Set `disp-sys-firewall` as NetVM for other AppVMs:
|
||||
4. Set `disp-sys-firewall` as NetVM for other app qubes:
|
||||
|
||||
```shell_session
|
||||
[user@dom0 ~]$ qvm-prefs <vm_name> netvm disp-sys-firewall
|
||||
|
||||
@ -17,14 +17,14 @@ These functions are manual and do not require any Qubes specific tools. All step
|
||||
- LUKS encrypted disk
|
||||
- LVM based VM storage
|
||||
|
||||
Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated AppVM.
|
||||
Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated app qube.
|
||||
This can be done with the command `qvm-block attach <isolated vm> dom0:<disk>` in dom0.
|
||||
|
||||
Decrypting the Disk
|
||||
-----------------
|
||||
|
||||
1. Find the disk to be accessed:
|
||||
1. Open a Linux terminal in either dom0 or the AppVM the disk was passed through to and enter `lsblk`, which will result in an output similar to the following.
|
||||
1. Open a Linux terminal in either dom0 or the app qube the disk was passed through to and enter `lsblk`, which will result in an output similar to the following.
|
||||
In this example, the currently booted Qubes system is installed on `sda` and the qubes system to be accessed is on `nvme0n1p2`.
|
||||
|
||||
```
|
||||
@ -58,7 +58,7 @@ Decrypting the Disk
|
||||
Accessing LVM Logical Volumes
|
||||
-----------------------------
|
||||
|
||||
3. If using an AppVM or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4.
|
||||
3. If using an app qube or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4.
|
||||
1. Qubes uses the default name `qubes_dom0` for it's LVM VG.
|
||||
This will conflict with the name of the VG of the currently installed system.
|
||||
To read both, you will have to rename the VG.
|
||||
@ -91,7 +91,7 @@ Reverting Changes
|
||||
|
||||
Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot.
|
||||
However, LVM will not allow an VG to be renamed to a name already in use.
|
||||
Thes steps must occur either in an AppVM or using recovery media.
|
||||
Thes steps must occur either in an app qube or using recovery media.
|
||||
|
||||
1. Unmount any disks that were accessed.
|
||||
2. Rename the VG back to qubes\_dom0 using the command `vgrename other_install qubes_dom0`.
|
||||
|
||||
@ -85,7 +85,7 @@ zpool online -e poolname ada0
|
||||
|
||||
#### Linux
|
||||
|
||||
Qubes will automatically grow the filesystem for you on all AppVMs with Qubes packages installed (which are all AppVMs installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe).
|
||||
Qubes will automatically grow the filesystem for you on all app qubes with Qubes packages installed (which are all app qubes installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe).
|
||||
Otherwise, you will see that there is unallocated free space at the end of your primary disk.
|
||||
You can use standard linux tools like `fdisk` and `resize2fs` to make this space available.
|
||||
|
||||
|
||||
@ -243,8 +243,8 @@ optional arguments:
|
||||
--skip-dom0 Skip dom0 configuration (VM creation etc)
|
||||
--targets TARGETS Coma separated list of VMs to target
|
||||
--templates Target all templates
|
||||
--app Target all AppVMs
|
||||
--all Target all non-disposable VMs (TemplateVMs and AppVMs)
|
||||
--app Target all app qubes
|
||||
--all Target all non-disposable VMs (TemplateVMs and app qubes)
|
||||
```
|
||||
|
||||
To apply a state to all templates, call `qubesctl --templates state.highstate`.
|
||||
@ -262,7 +262,7 @@ Beginning with Qubes 4.0 and after [QSB #45](/news/2018/12/03/qsb-45/), we imple
|
||||
|
||||
1. Added the `management_dispvm` VM property, which specifies the DVM
|
||||
Template that should be used for management, such as Salt
|
||||
configuration. TemplateBasedVMs inherit this property from their
|
||||
configuration. App qubes inherit this property from their
|
||||
parent TemplateVMs. If the value is not set explicitly, the default
|
||||
is taken from the global `management_dispvm` property. The
|
||||
VM-specific property is set with the `qvm-prefs` command, while the
|
||||
@ -451,31 +451,31 @@ Whonix gateway ProxyVM
|
||||
|
||||
#### `qvm.personal`
|
||||
|
||||
Personal AppVM
|
||||
Personal app qube
|
||||
|
||||
#### `qvm.work`
|
||||
|
||||
Work AppVM
|
||||
Work app qube
|
||||
|
||||
#### `qvm.untrusted`
|
||||
|
||||
Untrusted AppVM
|
||||
Untrusted app qube
|
||||
|
||||
#### `qvm.vault`
|
||||
|
||||
Vault AppVM with no NetVM enabled.
|
||||
Vault app qube with no NetVM enabled.
|
||||
|
||||
#### `qvm.default-dispvm`
|
||||
|
||||
Default DisposableVM template - fedora-26-dvm AppVM
|
||||
Default DisposableVM template - fedora-26-dvm app qube
|
||||
|
||||
#### `qvm.anon-whonix`
|
||||
|
||||
Whonix workstation AppVM.
|
||||
Whonix workstation app qube.
|
||||
|
||||
#### `qvm.whonix-ws-dvm`
|
||||
|
||||
Whonix workstation AppVM for Whonix DisposableVMs.
|
||||
Whonix workstation app qube for Whonix DisposableVMs.
|
||||
|
||||
#### `qvm.updates-via-whonix`
|
||||
|
||||
@ -545,7 +545,7 @@ VM type. Possible values:
|
||||
- `admin` - Administration domain (`dom0`)
|
||||
- `template` - Template VM
|
||||
- `standalone` - Standalone VM
|
||||
- `app` - Template based AppVM
|
||||
- `app` - Template based app qube
|
||||
|
||||
### `qubes:template`
|
||||
|
||||
|
||||
@ -12,12 +12,12 @@ title: Secondary Storage
|
||||
|
||||
|
||||
Suppose you have a fast but small primary SSD and a large but slow secondary HDD.
|
||||
You want to store a subset of your AppVMs on the HDD.
|
||||
You want to store a subset of your app qubes on the HDD.
|
||||
|
||||
## Instructions
|
||||
|
||||
Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks.
|
||||
For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
|
||||
For example, you can keep templates on one disk and app qubes on another, without messy symlinks.
|
||||
|
||||
These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD.
|
||||
See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section.
|
||||
|
||||
@ -109,8 +109,8 @@ Several invocations of `qvm-start` command (as shown above) might be needed.
|
||||
|
||||
## Setting up networking for HVMs
|
||||
|
||||
Just like standard paravirtualized AppVMs, the HVM qubes get fixed IP addresses centrally assigned by Qubes.
|
||||
Normally Qubes agent scripts (or services on Windows) running within each AppVM are responsible for setting up networking within the VM according to the configuration created by Qubes (through [keys](/doc/vm-interface/#qubesdb) exposed by dom0 to the VM).
|
||||
Just like standard paravirtualized app qubes, the HVM qubes get fixed IP addresses centrally assigned by Qubes.
|
||||
Normally Qubes agent scripts (or services on Windows) running within each app qube are responsible for setting up networking within the VM according to the configuration created by Qubes (through [keys](/doc/vm-interface/#qubesdb) exposed by dom0 to the VM).
|
||||
Such centrally managed networking infrastructure allows for [advanced networking configuration](https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html).
|
||||
|
||||
A generic HVM domain such as a standard Windows or Ubuntu installation, however, has no Qubes agent scripts running inside it initially and thus requires manual configuration of networking so that it matches the values assigned by Qubes for this qube.
|
||||
@ -149,7 +149,7 @@ Please see [this page](/doc/windows-appvms/) for specific advice on installing a
|
||||
|
||||
## Cloning HVMs
|
||||
|
||||
Just like normal AppVMs, the HVM domains can also be cloned either using the command-line `qvm-clone` or via the Qube Manager's 'Clone VM' option in the right-click menu.
|
||||
Just like normal app qubes, the HVM domains can also be cloned either using the command-line `qvm-clone` or via the Qube Manager's 'Clone VM' option in the right-click menu.
|
||||
|
||||
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
|
||||
|
||||
@ -249,7 +249,7 @@ timezone : localtime
|
||||
|
||||
## Assigning PCI devices to HVMs
|
||||
|
||||
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal AppVMs.
|
||||
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal app qubes.
|
||||
E.g. one can assign one of the USB controllers to the Windows VM and should be able to use various devices that require Windows software, such as phones, electronic devices that are configured via FTDI, etc.
|
||||
|
||||
One problem at the moment however, is that after the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working and should be restarted within the VM.
|
||||
@ -268,7 +268,7 @@ About 60 GB of disk space is required for conversion.
|
||||
Use an external harddrive if needed.
|
||||
The final root.img size is 40 GB.
|
||||
|
||||
In Debian AppVM, install `qemu-utils` and `unzip`:
|
||||
In Debian app qube, install `qemu-utils` and `unzip`:
|
||||
|
||||
~~~
|
||||
sudo apt install qemu-utils unzip
|
||||
|
||||
@ -19,7 +19,7 @@ shutdown. (Note that this is a different, lower level activity than the
|
||||
In Qubes, when you create a new VM, it's volumes are stored in one of the
|
||||
system's [Storage Pools](/doc/storage-pools/). On pool creation, a
|
||||
revisions_to_keep default value is set for the entire pool. (For a pool creation
|
||||
example, see [Storing AppVMs on Secondary Drives](/doc/secondary-storage/).)
|
||||
example, see [Storing app qubes on Secondary Drives](/doc/secondary-storage/).)
|
||||
Thereafter, each volume associated with a VM that is stored in this pool
|
||||
inherits the pool default revisions_to_keep.
|
||||
|
||||
|
||||
@ -71,7 +71,7 @@ Cons:
|
||||
(This mainly applies if you're upgrading from a previous version of Qubes.)
|
||||
Currently, the only options for recording optical discs (e.g., CDs, DVDs, BRDs) in Qubes are:
|
||||
1. Use a USB optical drive.
|
||||
2. Attach a SATA optical drive to a secondary SATA controller, then assign this secondary SATA controller to an AppVM.
|
||||
2. Attach a SATA optical drive to a secondary SATA controller, then assign this secondary SATA controller to an app qube.
|
||||
3. Use a SATA optical drive attached to dom0.
|
||||
|
||||
(Option 3 violates the Qubes security model since it entails transferring an untrusted ISO to dom0 in order to burn it to disc, which leaves only the other two options.)
|
||||
|
||||
@ -82,11 +82,11 @@ Restore from your backup
|
||||
4. Go to **Qubes menu -> System Tools -> Qubes Manager** to start it.
|
||||
|
||||
5. Follow the **Restoring from a Backup** section in the [Backup, Restoration, and Migration](/doc/backup-restore/) guide.
|
||||
We recommend that you restore only your [TemplateBasedVMs](/doc/glossary/#templatebasedvm) and [StandaloneVMs](/doc/glossary/#standalonevm) from R3.2.
|
||||
We recommend that you restore only your [app qubes](/doc/glossary/#app-qube) and [StandaloneVMs](/doc/glossary/#standalonevm) from R3.2.
|
||||
Using [TemplateVMs](/doc/templates/) and [SystemVMs](/doc/glossary/#systemvm) from R3.2 is not fully supported (see [#3514](https://github.com/QubesOS/qubes-issues/issues/3514)).
|
||||
Instead, we recommend using the TemplateVMs that were created specifically for R4.0, which you can [customize](/doc/software-update-vm/) according to your needs.
|
||||
For the TemplateVM OS versions supported in R4.0, see [Supported Versions](/doc/supported-versions/#templatevms).
|
||||
If the restore tool complains about missing templates, you can select the option to restore the AppVMs anyway, then change them afterward to use one of the default R4.0 templates.
|
||||
If the restore tool complains about missing templates, you can select the option to restore the app qubes anyway, then change them afterward to use one of the default R4.0 templates.
|
||||
|
||||
Note about additional disp-* qubes created during restore
|
||||
---------------------------------------------------------
|
||||
|
||||
@ -82,7 +82,7 @@ Among other things, this implies **proper DMAR ACPI table** construction.
|
||||
|
||||
Finally, we require that Qubes-certified hardware does not have any built-in _USB-connected_ microphones (e.g. as part of a USB-connected built-in camera) that cannot be easily physically disabled by the user, e.g. via a convenient mechanical switch.
|
||||
Thankfully, the majority of laptops on the market that we have seen already satisfy this condition out-of-the-box, because their built-in microphones are typically connected to the internal audio device, which itself is a type of PCIe device.
|
||||
This is important, because such PCIe audio devices are --- by default --- assigned to Qubes' (trusted) dom0 and exposed through our carefully designed protocol only to select AppVMs when the user explicitly chooses to do so.
|
||||
This is important, because such PCIe audio devices are --- by default --- assigned to Qubes' (trusted) dom0 and exposed through our carefully designed protocol only to select app qubes when the user explicitly chooses to do so.
|
||||
The rest of the time, they should be outside the reach of malware.
|
||||
|
||||
While we also recommend a physical kill switch on the built-in camera (or, if possible, not to have a built-in camera), we also recognize this isn't a critical requirement, because users who are concerned about it can easily cover it a piece of tape (something that, regrettably, is far less effective on a microphone).
|
||||
|
||||
@ -56,7 +56,7 @@ Creating a backup
|
||||
|
||||
3. Select the destination for the backup:
|
||||
|
||||
If you wish to send your backup to a (currently running) VM, select the VM in the drop-down box next to **Target AppVM**.
|
||||
If you wish to send your backup to a (currently running) VM, select the VM in the drop-down box next to **Target app qube**.
|
||||
If you wish to send your backup to a [USB mass storage device](/doc/usb/), you can use the directory selection widget to mount a connected device (under "Other locations" item on the left); or first mount the device in a VM, then select the mount point inside that VM as the backup destination.
|
||||
|
||||
You must also specify a directory on the device or in the VM, or a command to be executed in the VM as a destination for your backup.
|
||||
@ -95,7 +95,7 @@ This brings up the **Qubes Restore VMs** window.
|
||||
2. Select the source location of the backup to be restored:
|
||||
|
||||
- If your backup is located on a [USB mass storage device](/doc/usb/), attach it first to another VM or select `sys-usb` in the next item.
|
||||
- If your backup is located in a (currently running) VM, select the VM in the drop-down box next to **AppVM**.
|
||||
- If your backup is located in a (currently running) VM, select the VM in the drop-down box next to **app qube**.
|
||||
|
||||
You must also specify the directory and filename of the backup (or a command to be executed in a VM) in the **Backup file** field.
|
||||
If you followed the instructions in the previous section, "Creating a Backup," then your backup is most likely in the location you chose as the destination in step 3.
|
||||
|
||||
@ -21,7 +21,7 @@ Qubes OS supports the secure copying and moving of files and directories (folder
|
||||
|
||||
For simplicity, these instructions will refer to copying/moving a single file, but they apply equally well to groups of files and directories, which are copied recursively.
|
||||
|
||||
1. Open a file manager in the qube containing the file you wish to copy (the source qube), right-click on the file you wish to copy or move, and select `Copy to Other AppVM...` or `Move to Other AppVM...`.
|
||||
1. Open a file manager in the qube containing the file you wish to copy (the source qube), right-click on the file you wish to copy or move, and select `Copy to Other app qube...` or `Move to Other app qube...`.
|
||||
|
||||
2. A dialog box will appear in dom0 asking for the name of the target qube (qube B).
|
||||
Enter or select the desired destination qube name.
|
||||
|
||||
@ -67,7 +67,7 @@ The Qubes clipboard [RPC policy](/doc/rpc-policy/) is configurable in:
|
||||
~~~
|
||||
|
||||
You may wish to configure this policy in order to prevent user error.
|
||||
For example, if you are certain that you never wish to paste *into* your "vault" AppVM (and it is highly recommended that you do not), then you should edit the policy as follows:
|
||||
For example, if you are certain that you never wish to paste *into* your "vault" app qube (and it is highly recommended that you do not), then you should edit the policy as follows:
|
||||
|
||||
~~~
|
||||
@anyvm vault deny
|
||||
|
||||
@ -69,7 +69,7 @@ For this reason, there is no simple means of copying anything into dom0, unlike
|
||||
|
||||
There should normally be few reasons for the user to want to copy anything from domUs to dom0, as dom0 only acts as a "thin trusted terminal", and no user applications run there.
|
||||
Sometimes, new users feel the urge to copy a desktop wallpaper image into dom0, but that is not necessary.
|
||||
A safer approach is simply to display the image in [full-screen mode](/doc/full-screen-mode/) in an AppVM, then take a screenshot from dom0, which results in exactly the image needed for a wallpaper, created securely and natively in dom0.
|
||||
A safer approach is simply to display the image in [full-screen mode](/doc/full-screen-mode/) in an app qube, then take a screenshot from dom0, which results in exactly the image needed for a wallpaper, created securely and natively in dom0.
|
||||
|
||||
If you are determined to copy some files to dom0 anyway, you can use the following method.
|
||||
(If you want to copy text, first save it into a text file.)
|
||||
|
||||
@ -202,7 +202,7 @@ Example policy file in R4.0 (with Whonix installed, but not set as default Updat
|
||||
|
||||
### Installing Snap Packages
|
||||
|
||||
Snap packages do not use the normal update channels for Debian and Fedora (apt and dnf) and are often installed as the user rather than as root. To support these in an AppVM you need to take the following steps:
|
||||
Snap packages do not use the normal update channels for Debian and Fedora (apt and dnf) and are often installed as the user rather than as root. To support these in an app qube you need to take the following steps:
|
||||
|
||||
1. In the **template** you must install `snapd` and `qubes-snapd-helper`. Open a terminal in the template and run:
|
||||
|
||||
@ -256,29 +256,29 @@ Shutdown the template:
|
||||
[user@fedora-30-snap-demo ~]$ sudo shutdown -h now
|
||||
```
|
||||
|
||||
2. Now open the **AppVM** in which you would like to install the Snap application and run a terminal:
|
||||
2. Now open the **app qube** in which you would like to install the Snap application and run a terminal:
|
||||
|
||||
```shell_session
|
||||
[user@snap-demo-AppVM ~]$ snap install <package>
|
||||
[user@snap-demo-app qube ~]$ snap install <package>
|
||||
```
|
||||
|
||||
When the install is complete you can close the terminal window.
|
||||
|
||||
3. Refresh the Applications list for the AppVM.
|
||||
In the Qubes Menu for the **AppVM*** launch the Qube Settings.
|
||||
3. Refresh the Applications list for the app qube.
|
||||
In the Qubes Menu for the **app qube*** launch the Qube Settings.
|
||||
Then go to the Applications tab and click "Refresh Applications"
|
||||
|
||||
The refresh will take a few minutes; after it's complete the Snap app will appear in the AppVM's list of available applications. At this point the snap will be persistent within the AppVM and will receive updates when the AppVM is running.
|
||||
The refresh will take a few minutes; after it's complete the Snap app will appear in the app qube's list of available applications. At this point the snap will be persistent within the app qube and will receive updates when the app qube is running.
|
||||
|
||||
### Autostarting Installed Applications
|
||||
|
||||
If you want a desktop app to start automatically every time a qube starts you can create a link to it in the `~/.config/autostart` directory of the **AppVM**. This might be useful for Qubes that you set to automatically start on boot or for Qubes that have a set of apps you typically use all day, such as a chat app.
|
||||
If you want a desktop app to start automatically every time a qube starts you can create a link to it in the `~/.config/autostart` directory of the **app qube**. This might be useful for Qubes that you set to automatically start on boot or for Qubes that have a set of apps you typically use all day, such as a chat app.
|
||||
|
||||
1. Open a terminal in the **AppVM** where you would like the app to launch.
|
||||
1. Open a terminal in the **app qube** where you would like the app to launch.
|
||||
2. List the names of the available desktop shortcuts by running the command `ls /usr/share/applications` and find the exact name of the shortcut to the app you want to autostart:
|
||||
|
||||
```shell_session
|
||||
[user@example-AppVM ~]$ ls /usr/share/applications/
|
||||
[user@example-app qube ~]$ ls /usr/share/applications/
|
||||
bluetooth-sendto.desktop
|
||||
eog.desktop
|
||||
firefox.desktop
|
||||
@ -290,14 +290,14 @@ yelp.desktop
|
||||
3. Create the autostart directory:
|
||||
|
||||
```
|
||||
[user@example-AppVM ~]$ mkdir -p ~/.config/autostart
|
||||
[user@example-app qube ~]$ mkdir -p ~/.config/autostart
|
||||
```
|
||||
|
||||
4. Make a link to the desktop app file you'd like to start in the autostart directory. For example, the command below will link the Thunderbird app into the autostart directory:
|
||||
|
||||
```
|
||||
[user@example-AppVM ~]$ ln -s /usr/share/applications/mozilla-thunderbird.desktop ~/.config/autostart/mozilla-thunderbird.desktop
|
||||
[user@example-app qube ~]$ ln -s /usr/share/applications/mozilla-thunderbird.desktop ~/.config/autostart/mozilla-thunderbird.desktop
|
||||
```
|
||||
|
||||
Note that the app will autostart only when the AppVM starts. If you would like the AppVM to autostart, select the "Start qube automatically on boot" checkbox in the AppVM's Qube Settings.
|
||||
Note that the app will autostart only when the app qube starts. If you would like the app qube to autostart, select the "Start qube automatically on boot" checkbox in the app qube's Qube Settings.
|
||||
|
||||
|
||||
@ -36,8 +36,8 @@ In our example, this is `sys-usb:sda`, so hover over it.
|
||||
This will pop up a submenu showing running VMs to which the USB drive can be connected.
|
||||
Click on one and your USB drive will be attached!
|
||||
|
||||
**Note:** attaching individual partitions (e.g. `sys-usb:sda1`) can be slightly more secure because it doesn't force the target AppVM to parse the partition table.
|
||||
However, it often means the AppVM won't detect the new partition and you will need to manually mount it inside the AppVM.
|
||||
**Note:** attaching individual partitions (e.g. `sys-usb:sda1`) can be slightly more secure because it doesn't force the target app qube to parse the partition table.
|
||||
However, it often means the app qube won't detect the new partition and you will need to manually mount it inside the app qube.
|
||||
See below for more detailed steps.
|
||||
|
||||
## Block Devices in VMs
|
||||
|
||||
@ -16,10 +16,10 @@ title: How to Use 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.
|
||||
From inside an app qube, 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.
|
||||
DisposableVMs can be launched either directly from dom0's Start Menu or terminal window, or from within app qubes.
|
||||
While running, DisposableVMs will appear in Qubes VM Manager with the name `disp####`.
|
||||
|
||||
[](/attachment/wiki/DisposableVms/disposablevm-example.png)
|
||||
@ -42,20 +42,20 @@ When it is essential to avoid leaving any trace, consider using [Tails](https://
|
||||
|
||||
## DisposableVMs and Networking
|
||||
|
||||
Similarly to how AppVMs are based on their underlying [TemplateVM](/doc/glossary/#templatevm), DisposableVMs are based on their underlying [DisposableVM Template](/doc/glossary/#disposablevm-template).
|
||||
Similarly to how app qubes are based on their underlying [TemplateVM](/doc/glossary/#templatevm), DisposableVMs are based on their underlying [DisposableVM Template](/doc/glossary/#disposablevm-template).
|
||||
R4.0 introduces the concept of multiple DisposableVM Templates, whereas R3.2 was limited to only one.
|
||||
|
||||
On a fresh installation of Qubes, the default DisposableVM 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` DisposableVM Template available for your use.
|
||||
|
||||
You can set any AppVM to have the ability to act as a DisposableVM Template with:
|
||||
You can set any app qube to have the ability to act as a DisposableVM Template with:
|
||||
|
||||
```
|
||||
qvm-prefs <vmname> template_for_dispvms True
|
||||
```
|
||||
|
||||
The default system wide DisposableVM 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 DisposableVM Template you specified.
|
||||
By combining the two, choosing `Open in DisposableVM` from inside an app qube will open the document in a DisposableVM based on the default DisposableVM 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 DisposableVM Template will be used to launch DisposableVMs from that VM.
|
||||
@ -66,13 +66,13 @@ qvm-prefs <VM> default_dispvm <DISPOSABLEVM_TEMPLATE>
|
||||
```
|
||||
|
||||
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 DisposableVM Template to use itself, so DisposableVMs launched from within the AppVM/DisposableVM Template would inherit the same settings.
|
||||
You can even set an app qube that has also been configured as a DisposableVM Template to use itself, so DisposableVMs launched from within the app qube/DisposableVM Template would inherit the same settings.
|
||||
|
||||
NetVM and firewall rules for DisposableVM Templates can be set as they can for a normal VM.
|
||||
By default a DisposableVM will inherit the NetVM and firewall settings of the DisposableVM 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 DisposableVM 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.
|
||||
This is a change in behaviour from R3.2, where DisposableVMs would inherit the settings of the app qube from which they were launched.
|
||||
Therefore, launching a DisposableVM from an app qube will result in it using the network/firewall settings of the DisposableVM Template on which it is based.
|
||||
For example, if an app qube uses sys-net as its NetVM, but the default system DisposableVM uses sys-whonix, any DisposableVM launched from this app qube 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.
|
||||
@ -96,11 +96,11 @@ qvm-run --dispvm=<DISPOSABLEVM_TEMPLATE> --service qubes.StartApp+NameOfApp
|
||||
|
||||
## 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 "View in DisposableVM" or "Edit in DisposableVM".
|
||||
In an app qube's file manager, right click on the file you wish to open in a DisposableVM, then choose "View in DisposableVM" or "Edit 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.
|
||||
If you have edited the file and saved the changes, the changed file will be saved back to the original app qube, overwriting the original.
|
||||
|
||||
 
|
||||
|
||||
@ -115,9 +115,9 @@ Once you close the viewing application the whole DisposableVM will be destroyed.
|
||||
|
||||
|
||||
|
||||
## Opening a file in a DisposableVM via command line (from AppVM)
|
||||
## Opening a file in a DisposableVM via command line (from app qube)
|
||||
|
||||
Use the `qvm-open-in-dvm` command from a terminal in your AppVM:
|
||||
Use the `qvm-open-in-dvm` command from a terminal in your app qube:
|
||||
|
||||
~~~
|
||||
[user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf
|
||||
@ -125,12 +125,12 @@ Use the `qvm-open-in-dvm` command from a terminal in your AppVM:
|
||||
|
||||
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
|
||||
## Starting an arbitrary program in a DisposableVM from an app qube
|
||||
|
||||
Sometimes it can be useful to start an arbitrary program in a DisposableVM.
|
||||
The DisposableVM will stay running so long as the process which started the DisposableVM has not exited.
|
||||
Some applications, such as GNOME Terminal, do not wait for the application to close before the process exits (details [here](https://github.com/QubesOS/qubes-issues/issues/2581#issuecomment-272664009)).
|
||||
Starting an arbitrary program can be done from an AppVM by running
|
||||
Starting an arbitrary program can be done from an app qube by running
|
||||
|
||||
~~~
|
||||
[user@vault ~]$ qvm-run '@dispvm' xterm
|
||||
|
||||
@ -17,7 +17,7 @@ Any [qube](#qube) that depends on a [template](#template) for its root filesyste
|
||||
|
||||
* Historical note: This term originally meant "a qube intended for running user software applications" (hence the name "app").
|
||||
|
||||
* Historical note: This is the preferred term replacing the deprecated term "TemplateBasedVM."
|
||||
* Historical note: This is the preferred term replacing the deprecated term "app qube."
|
||||
|
||||
disposable
|
||||
----------
|
||||
|
||||
@ -17,14 +17,14 @@ The Role of the Firewall
|
||||
**[Firewalling in Qubes](/doc/firewall/) is not intended to be a leak-prevention mechanism.**
|
||||
|
||||
There are several reasons for this, which will be explained below.
|
||||
However, the main reason is that Qubes cannot prevent an attacker who has compromised one AppVM with restrictive firewall rules from leaking data via cooperative covert channels through another compromised AppVM with nonrestrictive firewall rules.
|
||||
However, the main reason is that Qubes cannot prevent an attacker who has compromised one app qube with restrictive firewall rules from leaking data via cooperative covert channels through another compromised app qube with nonrestrictive firewall rules.
|
||||
|
||||
For example, suppose you have an `email` AppVM.
|
||||
For example, suppose you have an `email` app qube.
|
||||
You have set the firewall rules for `email` such that it can communicate only with your email server.
|
||||
Now suppose that an attacker sends you a GPG-encrypted message which exploits a hypothetical bug in the GnuPG process.
|
||||
There are now multiple ways the attacker could proceed to leak data (such as confidential email messages) from `email`.
|
||||
The most obvious way is by simply emailing the data to himself.
|
||||
Another possibility is that the attacker has also compromised another one of your AppVMs, such as your `netvm`, which is normally assumed to be untrusted and has unrestricted access to the network.
|
||||
Another possibility is that the attacker has also compromised another one of your app qubes, such as your `netvm`, which is normally assumed to be untrusted and has unrestricted access to the network.
|
||||
In this case, the attacker might move data from `email` to the `netvm` via a covert channel, such as the CPU cache.
|
||||
Such covert channels have been described and even implemented in some "lab environments" and might allow for bandwidths of even a few tens of bits/sec.
|
||||
It is unclear whether such channels could be implemented in a real world system, where multiple VMs are running at the same time, each handling tens or hundreds of processes, all using the same cache memory, but it is worth keeping in mind.
|
||||
@ -41,7 +41,7 @@ Types of Data Leaks
|
||||
|
||||
In order to understand and attempt to prevent data leaks in Qubes, we must distinguish among three different types of relevant data leaks:
|
||||
|
||||
1. **Intentional leaks.** Malicious software which actively tries to leak data out of an AppVM, perhaps via cooperative covert channels established with other malicious software in another AppVM or on some server via networking, if networking, even limited, is allowed for the AppVM.
|
||||
1. **Intentional leaks.** Malicious software which actively tries to leak data out of an app qube, perhaps via cooperative covert channels established with other malicious software in another app qube or on some server via networking, if networking, even limited, is allowed for the app qube.
|
||||
|
||||
2. **Intentional sniffing.** Malicious software trying to use side channels to, e.g., actively guess some key material used in another VM by some non-malicious software there (e.g., non-leak-proof GPG accidentally leaking out bits of the private key by generating some timing patterns when using this key for some crypto operation).
|
||||
Such attacks have been described in the academic literature, but it is doubtful that they would succeed in practice in a moderately busy general purpose system like Qubes OS where the attacker normally has no way to trigger the target crypto operation explicitly and it is normally required that the attacker trigger many such operations.
|
||||
@ -49,7 +49,7 @@ Such attacks have been described in the academic literature, but it is doubtful
|
||||
3. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data, whether by design or accident.
|
||||
For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
|
||||
|
||||
Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an AppVM to "none") can fully protect against leaks of type 3.
|
||||
Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
|
||||
However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
|
||||
There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
|
||||
It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
|
||||
|
||||
@ -494,7 +494,7 @@ Where to put firewall rules
|
||||
---------------------------
|
||||
|
||||
Implicit in the above example [scripts](/doc/config-files/), but worth calling attention to: for all qubes *except* those supplying networking, iptables commands should be added to the `/rw/config/rc.local` script.
|
||||
For AppVMs supplying networking (`sys-firewall` inclusive), iptables commands should be added to `/rw/config/qubes-firewall-user-script`.
|
||||
For app qubes supplying networking (`sys-firewall` inclusive), iptables commands should be added to `/rw/config/qubes-firewall-user-script`.
|
||||
|
||||
Firewall troubleshooting
|
||||
------------------------
|
||||
|
||||
@ -16,7 +16,7 @@ ref: 168
|
||||
title: Split GPG
|
||||
---
|
||||
|
||||
Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the "smart card" is played by another Qubes AppVM.
|
||||
Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the "smart card" is played by another Qubes app qube.
|
||||
This way one not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations -- such as encryption/decryption and signing -- to another, more trusted, network-isolated domain.
|
||||
This way the compromise of your domain where Thunderbird or another client app is running -- arguably a not-so-unthinkable scenario -- does not allow the attacker to automatically also steal all your keys.
|
||||
(We should make a rather obvious comment here that the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.)
|
||||
@ -64,9 +64,9 @@ For Fedora:
|
||||
|
||||
### Setting up the GPG backend domain
|
||||
|
||||
First, create a dedicated AppVM for storing your keys (we will be calling it the GPG backend domain).
|
||||
First, create a dedicated app qube for storing your keys (we will be calling it the GPG backend domain).
|
||||
It is recommended that this domain be network disconnected (set its netvm to `none`) and only used for this one purpose.
|
||||
In later examples this AppVM is named `work-gpg`, but of course it might have any other name.
|
||||
In later examples this app qube is named `work-gpg`, but of course it might have any other name.
|
||||
|
||||
Make sure that gpg is installed there.
|
||||
At this stage you can add the private keys you want to store there, or you can now set up Split GPG and add the keys later.
|
||||
@ -116,7 +116,7 @@ ssb 4096R/30498E2A 2012-11-15
|
||||
(...)
|
||||
```
|
||||
|
||||
Note that running normal `gpg -K` in the demo above shows no private keys stored in this AppVM.
|
||||
Note that running normal `gpg -K` in the demo above shows no private keys stored in this app qube.
|
||||
|
||||
A note on `gpg` and `gpg2`:
|
||||
|
||||
@ -125,20 +125,20 @@ If you encounter trouble while trying to set up Split GPG, make sure you're usin
|
||||
|
||||
### Advanced Configuration
|
||||
|
||||
The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable automatically based on the content of the file `/rw/config/gpg-split-domain`, which should be set to the name of the GPG backend VM. This file survives the AppVM reboot, of course.
|
||||
The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable automatically based on the content of the file `/rw/config/gpg-split-domain`, which should be set to the name of the GPG backend VM. This file survives the app qube reboot, of course.
|
||||
|
||||
```shell_session
|
||||
[user@work-email ~]$ sudo bash
|
||||
[root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
|
||||
```
|
||||
|
||||
Split GPG's default qrexec policy requires the user to enter the name of the AppVM containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` place the following line at the top of the file `/etc/qubes-rpc/policy/qubes.Gpg`:
|
||||
Split GPG's default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` place the following line at the top of the file `/etc/qubes-rpc/policy/qubes.Gpg`:
|
||||
|
||||
```
|
||||
work-email work-gpg allow
|
||||
```
|
||||
|
||||
where `work-email` is the Thunderbird + Enigmail AppVM and `work-gpg` contains your GPG keys.
|
||||
where `work-email` is the Thunderbird + Enigmail app qube and `work-gpg` contains your GPG keys.
|
||||
|
||||
You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append `,default_target=<vmname>` to `ask` in `/etc/qubes-rpc/policy/qubes.Gpg`. For the examples given on this page:
|
||||
|
||||
@ -146,7 +146,7 @@ You may also edit the qrexec policy file for Split GPG in order to tell Qubes yo
|
||||
@anyvm @anyvm ask,default_target=work-gpg
|
||||
```
|
||||
|
||||
Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple AppVMs with Split GPG set up.
|
||||
Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up.
|
||||
|
||||
## Using Thunderbird
|
||||
|
||||
@ -222,7 +222,7 @@ The following command will configure Keybase to use `/usr/bin/qubes-gpg-client-w
|
||||
$ keybase config set gpg.command /usr/bin/qubes-gpg-client-wrapper
|
||||
```
|
||||
|
||||
Now that Keybase is configured to use `qubes-gpg-client-wrapper`, you will be able to use `keybase pgp select` to choose a GPG key from your backend GPG AppVM and link that key to your Keybase identity.
|
||||
Now that Keybase is configured to use `qubes-gpg-client-wrapper`, you will be able to use `keybase pgp select` to choose a GPG key from your backend GPG app qube and link that key to your Keybase identity.
|
||||
|
||||
## Using Git with Split GPG
|
||||
|
||||
@ -271,7 +271,7 @@ Now you can use `git stag` to add a signed tag to a commit and `git vtag` to ver
|
||||
|
||||
## Importing public keys
|
||||
|
||||
Use `qubes-gpg-import-key` in the client AppVM to import the key into the GPG backend VM.
|
||||
Use `qubes-gpg-import-key` in the client app qube to import the key into the GPG backend VM.
|
||||
|
||||
```shell_session
|
||||
[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
|
||||
|
||||
@ -39,7 +39,7 @@ To use this mode you need to:
|
||||
```
|
||||
|
||||
Shut down your TemplateVM.
|
||||
Then, either reboot your USB VM (so changes inside the TemplateVM take effect in your USB TemplateBasedVM) or install the packages inside your USB VM if you would like to avoid rebooting it.
|
||||
Then, either reboot your USB VM (so changes inside the TemplateVM take effect in your USB app qube) or install the packages inside your USB VM if you would like to avoid rebooting it.
|
||||
|
||||
2. Configure your YubiKey for challenge-response `HMAC-SHA1` mode, for example [following this tutorial](https://www.yubico.com/products/services-software/personalization-tools/challenge-response/).
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ After installing a fresh Debian TemplateVM, we recommend performing the followin
|
||||
|
||||
1. [Update the TemplateVM](/doc/software-update-vm/).
|
||||
|
||||
2. [Switch any TemplateBasedVMs that are based on the old TemplateVM to the new one](/doc/templates/#switching).
|
||||
2. [Switch any app qubes that are based on the old TemplateVM to the new one](/doc/templates/#switching).
|
||||
|
||||
3. If desired, [uninstall the old TemplateVM](/doc/templates/#uninstalling).
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ After installing a fresh Fedora TemplateVM, we recommend performing the followin
|
||||
|
||||
1. [Update the TemplateVM](/doc/software-update-vm/).
|
||||
|
||||
2. [Switch any TemplateBasedVMs that are based on the old TemplateVM to the new one](/doc/templates/#switching).
|
||||
2. [Switch any app qubes that are based on the old TemplateVM to the new one](/doc/templates/#switching).
|
||||
|
||||
3. If desired, [uninstall the old TemplateVM](/doc/templates/#uninstalling).
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ To update or install packages, execute the following command in dom0 (where `X`
|
||||
This opens a root terminal in the Minimal TemplateVM, from which you can use execute root commands without `sudo`.
|
||||
You will have to do this every time if you choose not to enable passwordless root.
|
||||
|
||||
If you want to be able to use `sudo` inside a Minimal TemplateVM (or TemplateBasedVMs based on a Minimal TemplateVM), open a root terminal as just instructed, then install the `qubes-core-agent-passwordless-root` package.
|
||||
If you want to be able to use `sudo` inside a Minimal TemplateVM (or app qubes based on a Minimal TemplateVM), open a root terminal as just instructed, then install the `qubes-core-agent-passwordless-root` package.
|
||||
|
||||
Optionally, verify that passwordless root now works by opening a normal (non-root) xterm window in the Minimal TemplateVM, then issue the command `sudo -l`.
|
||||
This should give you output that includes the `NOPASSWD` keyword.
|
||||
|
||||
@ -11,8 +11,8 @@ ref: 202
|
||||
title: App Menu Shortcut Troubleshooting
|
||||
---
|
||||
|
||||
For ease of use Qubes aggregates shortcuts to applications that are installed in AppVMs and shows them in one application menu (aka "app menu" or "start menu") in dom0.
|
||||
Clicking on such shortcut runs the assigned application in its AppVM.
|
||||
For ease of use Qubes aggregates shortcuts to applications that are installed in app qubes and shows them in one application menu (aka "app menu" or "start menu") in dom0.
|
||||
Clicking on such shortcut runs the assigned application in its app qube.
|
||||
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ What if my application has not been automatically included in the list of availa
|
||||
Some times applications may not have included a `.desktop` file and may not be detected by `qvm-sync-appmenus`.
|
||||
Other times, you may want to make a web shortcut available from the Qubes start menu.
|
||||
|
||||
You can manually create new entries in the "available applications" list of shortcuts for all AppVMs based on a TemplateVM.
|
||||
You can manually create new entries in the "available applications" list of shortcuts for all app qubes based on a TemplateVM.
|
||||
To do this:
|
||||
|
||||
1. Open a terminal window to the TemplateVM.
|
||||
@ -54,16 +54,16 @@ To do this:
|
||||
```
|
||||
|
||||
3. In dom0, run `qvm-sync-appmenus <TemplateVMName>`.
|
||||
4. Go to VM Settings of the AppVM(s) to which you want to add the new shortcut, then the Applications tab.
|
||||
4. Go to VM Settings of the app qube(s) to which you want to add the new shortcut, then the Applications tab.
|
||||
Move the newly created shortcut to the right under selected.
|
||||
|
||||
If you only want to create a shortcut for a single AppVM, you can create a custom menu entry instead:
|
||||
If you only want to create a shortcut for a single app qube, you can create a custom menu entry instead:
|
||||
|
||||
1. Open a terminal window to Dom0.
|
||||
2. Create a custom `.desktop` file in `~/.local/share/applications`.
|
||||
Look in the same directory for existing examples, or see the full [file specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html).
|
||||
You may use `qvm-run` inside the `.desktop` file; see [Behind the scenes](/doc/app-menu-shortcut-troubleshooting/#behind-the-scenes) for more details.
|
||||
3. Edit the `~/.config/menus/applications-merged/<vmname>-vm.menu` file for the AppVM.
|
||||
3. Edit the `~/.config/menus/applications-merged/<vmname>-vm.menu` file for the app qube.
|
||||
4. Add a custom menu entry referring to your newly created `.desktop` file.
|
||||
|
||||
~~~
|
||||
@ -102,16 +102,16 @@ Behind the scenes
|
||||
-----------------
|
||||
|
||||
`qvm-sync-appmenus` works by invoking *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
|
||||
This service enumerates installed applications and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates .desktop files in the AppVM/TemplateVM directory.
|
||||
This service enumerates installed applications and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates .desktop files in the app qube/TemplateVM directory.
|
||||
|
||||
For Linux VMs the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`.
|
||||
In Windows it's a PowerShell script located in `c:\Program Files\Invisible Things Lab\Qubes OS Windows Tools\qubes-rpc-services\get-appmenus.ps1` by default.
|
||||
|
||||
The list of installed applications for each AppVM is stored in dom0's `~/.local/share/qubes-appmenus/<vmname>/apps.templates`.
|
||||
The list of installed applications for each app qube is stored in dom0's `~/.local/share/qubes-appmenus/<vmname>/apps.templates`.
|
||||
Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*).
|
||||
Applications selected to appear in the menu are stored in `~/.local/share/qubes-appmenus/<vmname>/apps`.
|
||||
|
||||
Actual command lines for the menu shortcuts involve `qvm-run` command which starts a process in another domain.
|
||||
Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager` or `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox`
|
||||
|
||||
Note that you can create a shortcut that points to a .desktop file in your AppVM with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
|
||||
Note that you can create a shortcut that points to a .desktop file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user