From 4fc71ac4a9c638e61bb8a135462fb52ad49cee23 Mon Sep 17 00:00:00 2001 From: Andrew David Wong Date: Mon, 2 Sep 2019 04:34:26 -0500 Subject: [PATCH 1/5] Revamp documentation on managing OSes in Qubes - Unify and normalize Fedora and Debian docs - Deduplicate content - Cross-link pages - Move content to correct pages - Use more accurate and intuitive terms and names Fixes QubesOS/qubes-issues#5284 --- doc.md | 8 +- user/common-tasks/software-update-vm.md | 218 +++++------------ user/common-tasks/updating-qubes-os.md | 4 +- user/managing-os/debian/debian-minimal.md | 115 --------- .../debian/debian-upgrade-8-to-9.md | 91 ------- user/managing-os/debian/debian-upgrade.md | 208 +++++++++------- user/managing-os/debian/debian.md | 105 ++++---- user/managing-os/fedora/fedora-minimal.md | 134 ---------- .../fedora/fedora-upgrade-26-to-27.md | 208 ---------------- .../fedora/fedora-upgrade-27-to-28.md | 231 ------------------ .../fedora/fedora-upgrade-28-to-29.md | 212 ---------------- user/managing-os/fedora/fedora-upgrade.md | 213 ++++++++++++++++ user/managing-os/fedora/fedora.md | 51 ++-- user/managing-os/fedora/upgrade-29-to-30.md | 185 -------------- user/managing-os/hvm.md | 80 +++--- user/managing-os/minimal-templates.md | 174 +++++++++++++ user/managing-os/templates.md | 202 ++++++++++++--- 17 files changed, 875 insertions(+), 1564 deletions(-) delete mode 100644 user/managing-os/debian/debian-minimal.md delete mode 100644 user/managing-os/debian/debian-upgrade-8-to-9.md delete mode 100644 user/managing-os/fedora/fedora-minimal.md delete mode 100644 user/managing-os/fedora/fedora-upgrade-26-to-27.md delete mode 100644 user/managing-os/fedora/fedora-upgrade-27-to-28.md delete mode 100644 user/managing-os/fedora/fedora-upgrade-28-to-29.md create mode 100644 user/managing-os/fedora/fedora-upgrade.md delete mode 100644 user/managing-os/fedora/upgrade-29-to-30.md create mode 100644 user/managing-os/minimal-templates.md diff --git a/doc.md b/doc.md index 815cf4f9..350548c8 100644 --- a/doc.md +++ b/doc.md @@ -64,7 +64,7 @@ Core documentation for Qubes users. * [Copying from (and to) Dom0](/doc/copy-from-dom0/) * [Updating Qubes OS](/doc/updating-qubes-os/) * [Installing and Updating Software in Dom0](/doc/software-update-dom0/) - * [Installing and Updating Software in VMs](/doc/software-update-vm/) + * [Installing and Updating Software in DomUs](/doc/software-update-domu/) * [Backup, Restoration, and Migration](/doc/backup-restore/) * [DisposableVMs](/doc/disposablevm/) * [Block (or Storage) Devices](/doc/block-devices/) @@ -78,12 +78,8 @@ Core documentation for Qubes users. ### Managing Operating Systems within Qubes * [TemplateVMs](/doc/templates/) - * [Template: Fedora](/doc/templates/fedora/) - * [Template: Fedora Minimal](/doc/templates/fedora-minimal/) - * [Template: Debian](/doc/templates/debian/) - * [Template: Debian Minimal](/doc/templates/debian-minimal/) * [Windows](/doc/windows/) - * [HVM Domains](/doc/hvm/) + * [StandaloneVMs and HVMs](/doc/standalone-and-hvm/) ### Security in Qubes diff --git a/user/common-tasks/software-update-vm.md b/user/common-tasks/software-update-vm.md index bebc633c..ccc83b2e 100644 --- a/user/common-tasks/software-update-vm.md +++ b/user/common-tasks/software-update-vm.md @@ -1,55 +1,50 @@ --- layout: doc -title: Installing and updating software in VMs -permalink: /doc/software-update-vm/ +title: Installing and updating software in domUs +permalink: /doc/software-update-domu/ redirect_from: +- /doc/software-update-vm/ - /en/doc/software-update-vm/ - /doc/SoftwareUpdateVM/ - /wiki/SoftwareUpdateVM/ --- -Installing and updating software in VMs -======================================= +# Installing and updating software in domUs -Updating TemplateVMs and StandaloneVMs are two of the main steps in [Updating Qubes OS]. -It is very import to keep TemplateVMs and StandaloneVMs up-to-date with the latest [security] updates. +Updating [domUs], especially [TemplateVMs] and [StandaloneVMs][StandaloneVM] are important steps in [Updating Qubes OS]. +It is very import to keep domUs up-to-date with the latest [security] updates. Updating these VMs also allows you to receive various non-security bug fixes and enhancements both from the Qubes OS Project and from your upstream distro maintainer. -How TemplateVMs work in Qubes ------------------------------- -Most of the AppVMs (domains) are based on a *TemplateVM*, which means that their root filesystem (i.e. all the programs and system files) is based on the root filesystem of the corresponding template VM. -This dramatically saves disk space, because each new AppVM needs disk space only for storing the user's files (i.e. the home directory). -Of course the AppVM has only read-access to the template's filesystem -- it cannot modify it in any way. +## Installing software in TemplateVMs -In addition to saving on the disk space, and reducing domain creation time, another advantage of such scheme is the possibility for centralized software update. -It's just enough to do the update in the template VM, and then all the AppVMs based on this template get updates automatically after they are restarted. +To permanently install new software in a TemplateVM: -The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home`, `/usr/local`, or `/rw` then it will disappear after the AppVM reboots (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). -**This means one normally installs software in the TemplateVM, not in AppVMs.** + 1. Start the TemplateVM. + 2. Start either a terminal (e.g. `gnome-terminal`) or a dedicated software management application, such as `gpk-application`. + 3. Install software as normally instructed inside that operating system (e.g. using `dnf`, or the dedicated GUI application). + 4. Shut down the TemplateVM. + 5. Restart all [TemplateBasedVMs] based on the TemplateVM. -The template root filesystem is created in a thin pool, so manual trims are not necessary. -See [here](/doc/disk-trim) for further discussion on enabling discards/trim support. -Installing (or updating) software in the TemplateVM ----------------------------------------------------- +## Updating software in TemplateVMs -In order to permanently install new software, you should: +The recommended way to update your TemplateVMs is to use the **Qubes Update** tool. +By default, the icon for this tool will appear in your Notification Area when updates are available. +Simply click on it and follow the guided steps. +If you wish to open this tool directly, you can find it in the System Tools area of the Applications menu. -- Start the template VM and then start either console (e.g. `gnome-terminal`) or dedicated software management application, such as `gpk-application` (*Start-\>Applications-\>Template: fedora-XX-\>Add/Remove software*), +You can also update TemplateVMs individually. +In the Qube Manager, select the desired TemplateVM, then click **Update qube**. +Advanced users can execute the standard update command for that operating system from the command line, e.g., `dnf update` in Fedora and `apt-get update` in Debian. -- Install/update software as usual (e.g. using dnf, or the dedicated GUI application). - Then, shutdown the template VM. -- You will see now that all the AppVMs based on this template (by default all your VMs) will be marked as "outdated" in the manager. - This is because their filesystems have not been yet updated -- in order to do that, you must restart each VM. - You don't need to restart all of them at the same time -- e.g. if you just need the newly installed software to be available in your 'personal' domain, then restart only this VM. - You can restart others whenever this will be convenient to you. +## Testing repositories -Testing repositories --------------------- +If you wish to install updates that are still in [testing], you must enable the appropriate testing repositories. -### Fedora ### + +### Fedora There are three Qubes VM testing repositories (where `*` denotes the Release): @@ -68,7 +63,8 @@ sudo dnf upgrade --enablerepo=qubes-vm-*-unstable To enable or disable any of these repos permanently, change the corresponding `enabled` value to `1` in `/etc/yum.repos.d/qubes-*.repo`. -### Debian ### + +### Debian Debian also has three Qubes VM testing repositories (where `*` denotes the Release): @@ -78,8 +74,8 @@ Debian also has three Qubes VM testing repositories (where `*` denotes the Relea To enable or disable any of these repos permanently, uncomment the corresponding `deb` line in `/etc/apt/sources.list.d/qubes-r*.list` -Reverting changes to a TemplateVM ---------------------------------- + +## Reverting changes to a TemplateVM Perhaps you've just updated your TemplateVM, and the update broke your template. Or perhaps you've made a terrible mistake, like accidentally confirming the installation of an unsigned package that could be malicious. @@ -90,108 +86,49 @@ This means that if you have already restarted the TemplateVM, using this command On the other hand, if the template is already broken or compromised, it won't hurt to try reverting first. Just make sure to **back up** all of your data and changes first! -For example, to revert changes to the `fedora-26` TemplateVM: +For example, to revert changes to the `fedora-XX` TemplateVM (where `XX` is your Fedora version): -1. Shut down `fedora-26`. +1. Shut down `fedora-XX`. If you've already just shut it down, do **not** start it again (see above). 2. In a dom0 terminal, type: - qvm-volume revert fedora-26:root - -Notes on trusting your TemplateVM(s) -------------------------------------- - -As the TemplateVM is used for creating filesystems for other AppVMs where you actually do the work, it means that the TemplateVM is as trusted as the most trusted AppVM based on this template. -In other words, if your template VM gets compromised, e.g. because you installed an application, whose *installer's scripts* were malicious, then *all* your AppVMs (based on this template) will inherit this compromise. - -There are several ways to deal with this problem: - -- Only install packages from trusted sources -- e.g. from the pre-configured Fedora repositories. - All those packages are signed by Fedora, and we expect that at least the package's installation scripts are not malicious. - This is enforced by default (at the [firewall VM level](/doc/firewall/)), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos. - -- Use *standalone VMs* (see below) for installation of untrusted software packages. - -- Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted AppVMs, would get various packages from less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos. - -Some popular questions: - -- So, why should we actually trust Fedora repos -- it also contains large amount of third-party software that might be buggy, right? - -As far as the template's compromise is concerned, it doesn't really matter whether `/usr/bin/firefox` is buggy and can be exploited, or not. -What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. -Template VM should be used only for installation of packages, and nothing more, so it should never get a chance to actually run `/usr/bin/firefox` and get infected from it, in case it was compromised. -Also, some of your more trusted AppVMs would have networking restrictions enforced by the [firewall VM](/doc/firewall/), and again they should not fear this proverbial `/usr/bin/firefox` being potentially buggy and easy to compromise. - -- But why trust Fedora? - -Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for Dom0 packages and for AppVM packages). -We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in Dom0. -We had to trust *somebody* as we are unable to write all the software from scratch ourselves. -But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. -We certainly do not assume the latter. - -- So, are the template VMs as trusted as Dom0? - -Not quite. -Dom0 compromise is absolutely fatal, and it leads to Game OverTM. -However, a compromise of a template affects only a subset of all your AppVMs (in case you use more than one template, or also some standalone VMs). -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 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