Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-24 14:59:25 -05:00
Code Issues Packages Projects Releases Wiki Activity

Update links

Browse Source
This commit is contained in:
Andrew David Wong 2020-09-13 08:19:29 -05:00
parent 3f6363ec49
commit 3110a406b6
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
3 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
external/security-guides/security-guidelines.md vendored
View File

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

4
introduction/intro.html
View File

@ -39,7 +39,7 @@ redirect_from:
</li>
<li class="more-bottom">
<b>Natures:</b> <a href="/doc/standalone-and-hvm/">full-fledged</a> or
<a href="/getting-started/#appvms-qubes-and-templatevms">
<a href="/getting-started/">
stripped-down</a> virtual machines based on popular operating systems,
such as <a href="/doc/templates/fedora">Fedora</a>,
<a href="/doc/templates/debian">Debian</a>, and
@ -82,7 +82,7 @@ redirect_from:
<div class="col-lg-4 col-md-4 col-xs-12">
<h3>Template system</h3>
<p>
Use <a href="/getting-started/#appvms-qubes-and-templatevms">AppVMs</a> to
Use <a href="/getting-started/">AppVMs</a> to
share a root file system without sacrificing security using the innovative
<a href="/doc/templates/">Template system</a>.
</p>

2
user/advanced-configuration/resize-disk-image.md
View File

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