mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Merge branch 'master' into patch-2
This commit is contained in:
qtpies
GitHub
commit
886c17cdc7
@ -14,11 +14,10 @@ Qubes Architecture Overview
|
||||
|
||||
Qubes implements a Security by Isolation approach. To do this, Qubes utilizes virtualization technology in order to isolate various programs from each other and even to sandbox many system-level components, such as networking and storage subsystems, so that the compromise of any of these programs or components does not affect the integrity of the rest of the system.
|
||||
|
||||
[](/attachment/wiki/QubesArchitecture/qubes-schema-v2.png)
|
||||
|
||||
Qubes lets the user define many security domains, which are implemented as lightweight Virtual Machines (VMs), or “AppVMs.” For example, the user can have “personal,” “work,” “shopping,” “bank,” and “random” AppVMs and can use the applications within those VMs just as if they were executing on the local machine. At the same time, however, these applications are well isolated from each other. Qubes also supports secure copy-and-paste and file sharing between the AppVMs, of course.
|
||||
|
||||
[](/attachment/wiki/QubesArchitecture/qubes-arch-diagram-1.png)
|
||||
|
||||
(Note: In the diagram above, "Storage domain" is actually a USB domain.)
|
||||
|
||||
Key Architecture features
|
||||
-------------------------
|
||||
@ -33,4 +32,43 @@ Key Architecture features
|
||||
- Qubes GUI provides isolation between apps sharing the same desktop
|
||||
- Secure system boot based (optional)
|
||||
|
||||
[Architecture Spec v0.3 [PDF]](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) (The original 2009 document that started this all...)
|
||||
[Architecture Spec v0.3 [PDF]](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) is the original 2009 document that started this all.
|
||||
|
||||
|
||||
Qubes Core Stack
|
||||
----------------
|
||||
|
||||
Qubes Core Stack is, as the name implies, the core component of Qubes OS. It's
|
||||
the glue that connects all the other components together, and which allows users
|
||||
and admins to interact with and configure the system. The other components of
|
||||
the Qubes system include:
|
||||
|
||||
- VM-located core agents (implementing e.g. qrexec endpoints used by various
|
||||
Qubes services)
|
||||
- VM-customizations (making the VMs lightweight and working well with seamless
|
||||
GUI virtualization)
|
||||
- Qubes GUI virtualization (the protocol, VM-located agents, and daemons
|
||||
located in the GUI domain which, for now, happens to be the same as dom0),
|
||||
- GUI domain customizations (Desktop Environment customizations, decoration
|
||||
coloring plugin, etc)
|
||||
- The AdminVM distribution (various customizations, special services, such as
|
||||
for receiving and verifying updates, in the future: custom distro)
|
||||
- The Xen hypervisor (with a bunch of customization patches, occasional
|
||||
hardening) or - in the future - some other virtualising or containerizing
|
||||
software or technology
|
||||
- Multiple "Qubes Apps" (various services built on top of Qubes qrexec
|
||||
infrastructure, such as: trusted PDF and Image converters, Split GPG, safe
|
||||
USB proxies for HID devices, USB proxy for offering USB devices (exposed via
|
||||
qvm-usb), Yubikey support, USB Armory support, etc)
|
||||
- Various ready-to-use templates (e.g. Debian-, Whonix-based), which are used
|
||||
to create actual VMs, i.e. provide the root filesystem to the VMs
|
||||
- Salt Stack integration
|
||||
|
||||
And all these components are "glued together" by the Qubes Core Stack.
|
||||
|
||||
[](/attachment/wiki/QubesArchitecture/qubes-components.png)
|
||||
|
||||
This diagram illustrates the location of all these components in the overall
|
||||
system architecture. Unlike the other Qubes architecture diagram above, this one
|
||||
takes an AppVM-centric approach.
|
||||
|
||||
|
||||
@ -20,7 +20,9 @@ This means that you can safely work with untrusted files without risk of comprom
|
||||
DisposableVMs can be launched either directly from dom0's Start Menu or terminal window, or from within AppVMs.
|
||||
While running, DisposableVMs will appear in Qubes VM Manager with the name `disp####`.
|
||||
|
||||
See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a DisposableVM.
|
||||
[](/attachment/wiki/DisposableVms/disposablevm-example.png)
|
||||
|
||||
This diagram provides a general example of how DisposableVMs can be used to safely open untrusted links and attachments in DisposableVMs. See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a DisposableVM.
|
||||
|
||||
|
||||
## Security ##
|
||||
|
||||
@ -41,6 +41,8 @@ After installing a fresh Debian TemplateVM, we recommend performing the followin
|
||||
|
||||
## Updating
|
||||
|
||||
Routine daily updates within a given release.
|
||||
|
||||
Please see [Updating software in TemplateVMs].
|
||||
|
||||
|
||||
|
||||
@ -33,6 +33,8 @@ After installing a fresh Fedora TemplateVM, we recommend performing the followin
|
||||
|
||||
## Updating
|
||||
|
||||
Routine daily updates within a given release.
|
||||
|
||||
Please see [Updating software in TemplateVMs].
|
||||
|
||||
|
||||
@ -43,12 +45,6 @@ There are two ways to upgrade a TemplateVM. The easiest way is to [install] the
|
||||
You can also do an in-place upgrade of an installed Fedora TemplateVM. Please see [Upgrading Fedora TemplateVMs].
|
||||
|
||||
|
||||
## Release-specific notes
|
||||
|
||||
This section contains notes about specific Fedora releases.
|
||||
|
||||
(There is currently no release-specific information documented.)
|
||||
|
||||
|
||||
[TemplateVM]: /doc/templates/
|
||||
[Fedora Xfce]: /doc/templates/fedora-xfce/
|
||||
@ -62,3 +58,4 @@ This section contains notes about specific Fedora releases.
|
||||
[Updating software in TemplateVMs]: /doc/software-update-domu/#updating-software-in-templatevms
|
||||
[Upgrading Fedora TemplateVMs]: /doc/template/fedora/upgrade/
|
||||
[install]: /doc/templates/#installing
|
||||
|
||||
|
||||
@ -16,18 +16,16 @@ redirect_from:
|
||||
|
||||
# Qubes Split GPG #
|
||||
|
||||
## What is Split GPG and why should I use it instead of the standard 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" plays another Qubes AppVM.
|
||||
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.)
|
||||
|
||||
The diagram below presents the big picture of Split GPG architecture.
|
||||
[](/attachment/wiki/SplitGpg/split-gpg-diagram.png)
|
||||
|
||||
|
||||
This diagram presents an overview of the Split GPG architecture.
|
||||
|
||||
### Advantages of Split GPG vs. traditional GPG with a smart card ###
|
||||
## Advantages of Split GPG vs. traditional GPG with a smart card ##
|
||||
|
||||
It is often thought that the use of smart cards for private key storage guarantees ultimate safety.
|
||||
While this might be true (unless the attacker can find a usually-very-expensive-and-requiring-physical-presence way to extract the key from the smart card) but only with regards to the safety of the private key itself.
|
||||
@ -39,26 +37,8 @@ Unfortunately this problem of signing reliability is not solvable by Split GPG)
|
||||
With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
|
||||
This way it would be easy to spot unexpected requests to decrypt documents.
|
||||
|
||||
|
||||
|
||||
|
||||
### Current limitations ###
|
||||
|
||||
- Current implementation requires importing of public keys to the vault domain.
|
||||
This opens up an avenue to attack the gpg running in the backend domain via a hypothetical bug in public key importing code.
|
||||
See ticket [#474] for more details and plans how to get around this problem, as well as the section on [using Split GPG with subkeys] below.
|
||||
|
||||
- It doesn't solve the problem of allowing the user to know what is to be signed before the operation gets approved.
|
||||
Perhaps the GPG backend domain could start a DisposableVM and have the to-be-signed document displayed there? To Be Determined.
|
||||
|
||||
- The Split GPG client will fail to sign or encrypt if the private key in the GnuPG backend is protected by a passphrase.
|
||||
It will give an `Inappropriate ioctl for device` error.
|
||||
Do not set passphrases for the private keys in the GPG backend domain.
|
||||
Doing so won't provide any extra security anyway, as explained [above][intro] and [below][using Split GPG with subkeys].
|
||||
If you are generating a new key pair, or if you have a private key that already has a passphrase, you can use `gpg2 --edit-key <key_id>` then `passwd` to set an empty passphrase.
|
||||
Note that `pinentry` might show an error when you try to set an empty passphrase, but it will still make the change.
|
||||
(See [this StackExchange answer][se-pinentry] for more information.)
|
||||
Note: The error shows only if you **do not** have graphical pinentry installed.
|
||||
[](/attachment/wiki/SplitGpg/r2-split-gpg-1.png)
|
||||
[](/attachment/wiki/SplitGpg/r2-split-gpg-3.png)
|
||||
|
||||
## Configuring Split GPG ##
|
||||
|
||||
@ -151,7 +131,7 @@ You may also edit the qrexec policy file for Split GPG in order to tell Qubes yo
|
||||
|
||||
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.
|
||||
|
||||
### Using Thunderbird + Enigmail with Split GPG ###
|
||||
## Using Thunderbird + Enigmail with Split GPG ##
|
||||
|
||||
It is recommended to set up and use `/usr/bin/qubes-gpg-client-wrapper`, as discussed above, in Thunderbird through the Enigmail addon.
|
||||
|
||||
@ -159,9 +139,9 @@ It is recommended to set up and use `/usr/bin/qubes-gpg-client-wrapper`, as disc
|
||||
|
||||
On a fresh Enigmail install, your need to change the default `Enigmail Junior Mode`. Go to Thunderbird preferences and then privacy tab. Select `Force using S/MIME and Enigmail`. Then, in the preferences of Enigmail, make it point to `/usr/bin/qubes-gpg-client-wrapper` instead of the standard GnuPG binary:
|
||||
|
||||
|
||||
[](/attachment/wiki/SplitGpg/tb-enigmail-split-gpg-settings-2.png)
|
||||
|
||||
### Using Keybase with Split GPG ###
|
||||
## Using Keybase with Split GPG ##
|
||||
|
||||
Keybase, a security focused messaging and file-sharing app with GPG integration, can be configured to use Split GPG.
|
||||
|
||||
@ -215,15 +195,15 @@ 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.
|
||||
Of course a (safe, unspoofable) user consent dialog box is displayed to accept this.
|
||||
|
||||
[user@work ~]$ export QUBES_GPG_DOMAIN=work-gpg
|
||||
[user@work ~]$ qubes-gpg-import-key ~/Downloads/marmarek.asc
|
||||
|
||||
|
||||
A safe, unspoofable user consent dialog box is displayed.
|
||||
|
||||
<br />
|
||||
[](/attachment/wiki/SplitGpg/r2-split-gpg-5.png)
|
||||
|
||||
Selecting "Yes to All" will add a line in the corresponding [RPC Policy] file.
|
||||
|
||||
## Advanced: Using Split GPG with Subkeys ##
|
||||
|
||||
@ -241,8 +221,6 @@ In this example, the following keys are stored in the following locations (see b
|
||||
| `ssb` | `work-gpg` |
|
||||
| `pub` | `work-email` |
|
||||
|
||||
<br />
|
||||
|
||||
* `sec` (master secret key)
|
||||
|
||||
Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
|
||||
@ -324,6 +302,24 @@ As always, exercise caution and use your good judgment.)
|
||||
- ["GPG Offline Master Key w/ smartcard" maintained by Abel Luck][luck]
|
||||
- ["Using GnuPG with QubesOS" by Alex][apapadop]
|
||||
|
||||
## Current limitations ##
|
||||
|
||||
- Current implementation requires importing of public keys to the vault domain.
|
||||
This opens up an avenue to attack the gpg running in the backend domain via a hypothetical bug in public key importing code.
|
||||
See ticket [#474] for more details and plans how to get around this problem, as well as the section on [using Split GPG with subkeys].
|
||||
|
||||
- It doesn't solve the problem of allowing the user to know what is to be signed before the operation gets approved.
|
||||
Perhaps the GPG backend domain could start a DisposableVM and have the to-be-signed document displayed there? To Be Determined.
|
||||
|
||||
- The Split GPG client will fail to sign or encrypt if the private key in the GnuPG backend is protected by a passphrase.
|
||||
It will give an `Inappropriate ioctl for device` error.
|
||||
Do not set passphrases for the private keys in the GPG backend domain.
|
||||
Doing so won't provide any extra security anyway, as explained in the introduction and in [using Split GPG with subkeys].
|
||||
If you are generating a new key pair, or if you have a private key that already has a passphrase, you can use `gpg2 --edit-key <key_id>` then `passwd` to set an empty passphrase.
|
||||
Note that `pinentry` might show an error when you try to set an empty passphrase, but it will still make the change.
|
||||
(See [this StackExchange answer][se-pinentry] for more information.)
|
||||
Note: The error shows only if you **do not** have graphical pinentry installed.
|
||||
|
||||
|
||||
[#474]: https://github.com/QubesOS/qubes-issues/issues/474
|
||||
[using Split GPG with subkeys]: #advanced-using-split-gpg-with-subkeys
|
||||
@ -340,3 +336,5 @@ As always, exercise caution and use your good judgment.)
|
||||
[luck]: https://gist.github.com/abeluck/3383449
|
||||
[apapadop]: https://apapadop.wordpress.com/2013/08/21/using-gnupg-with-qubesos/
|
||||
[current-limitations]: #current-limitations
|
||||
[RPC Policy]: /doc/rpc-policy/
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user