From 3110a406b6636fdf698b0d6c5bea5f1594223b94 Mon Sep 17 00:00:00 2001 From: Andrew David Wong Date: Sun, 13 Sep 2020 08:19:29 -0500 Subject: [PATCH] Update links --- external/security-guides/security-guidelines.md | 2 +- introduction/intro.html | 4 ++-- user/advanced-configuration/resize-disk-image.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/external/security-guides/security-guidelines.md b/external/security-guides/security-guidelines.md index 4a85d552..a9beaf25 100644 --- a/external/security-guides/security-guidelines.md +++ b/external/security-guides/security-guidelines.md @@ -141,7 +141,7 @@ See [here](/doc/usb/). Dom0 Precautions ---------------- -As explained [here](/getting-started/#appvms-qubes-and-templatevms), dom0 should not be used for any user operations. There are several reasons for this: +As explained [here](/getting-started/), dom0 should not be used for any user operations. There are several reasons for this: 1. Secure isolation among domUs (i.e., AppVMs, StandaloneVMs, HVMs, etc.) is the *raison d'être* of Qubes. This is the primary reason that we recommend the delegation of all user activities to some number of AppVMs. In the event that any given VM is compromised, only that particular VM is compromised. (TemplateVMs are the exception to this. If a TemplateVM were compromised, then every AppVM based on it might also be compromised. Even in this case, however, the entire system would not necessarily have been compromised, since StandaloneVM(s), HVM(s), and/or multiple TemplateVMs might be in use.) By contrast, if dom0 were ever compromised, the entire system would thereby be compromised. 2. Due to the absence of convenience mechanisms in dom0 such as the inter-VM clipboard and inter-VM file copying, it is significantly less convenient to attempt to use dom0 for user operations (e.g., password management) in conjunction with AppVMs than it is to use another dedicated AppVM (e.g., a "vault" VM). diff --git a/introduction/intro.html b/introduction/intro.html index 991110dc..9b70fafd 100644 --- a/introduction/intro.html +++ b/introduction/intro.html @@ -39,7 +39,7 @@ redirect_from:
  • Natures: full-fledged or - + stripped-down virtual machines based on popular operating systems, such as Fedora, Debian, and @@ -82,7 +82,7 @@ redirect_from:

    Template system

    - Use AppVMs to + Use AppVMs to share a root file system without sacrificing security using the innovative Template system.

    diff --git a/user/advanced-configuration/resize-disk-image.md b/user/advanced-configuration/resize-disk-image.md index 7a74132e..a2e438be 100644 --- a/user/advanced-configuration/resize-disk-image.md +++ b/user/advanced-configuration/resize-disk-image.md @@ -33,7 +33,7 @@ In most cases, the GUI tool Qube Settings (available for every qube from the Sta ![vm-settings-disk-image.png](/attachment/wiki/DiskSize/vm-settings-disk-image.png) In case of standalone qubes and templates, just change the Disk Storage settings above. -In case of template-based qubes, the private storage (the /home directory and user files) can be changed in the qube's own settings, but the system root image is [inherited from the template](/getting-started/#appvms-qubes-and-templatevms), and so it must be changed in the template settings. +In case of template-based qubes, the private storage (the /home directory and user files) can be changed in the qube's own settings, but the system root image is [inherited from the template](/getting-started/), and so it must be changed in the template settings. If you are increasing the disk image size for Linux-based qubes installed from Qubes OS repositories in Qubes 4.0 or later, changing the settings above is all you need to do - in other cases, you may need to do more, according to instructions below. See also the OS-specific follow-up instructions below.