Mass replace "AppVM" and "TemplateBasedVM" with "app qube"

QubesOS/qubes-issues#1015

user/security-in-qubes/data-leaks.md

@@ -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).

user/security-in-qubes/firewall.md

@@ -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
 ------------------------

user/security-in-qubes/split-gpg.md

@@ -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

user/security-in-qubes/yubi-key.md

@@ -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/).