mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-01-13 08:19:43 -05:00
Merge branch 'master' of https://github.com/QubesOS/qubes-doc
This commit is contained in:
Brennan Novak
commit
7097a1b541
@ -11,7 +11,7 @@ redirect_from:
|
||||
Qubes Backup, Restoration, and Migration
|
||||
========================================
|
||||
|
||||
**Caution:** The Qubes backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971). It is *strongly recommended* that users select a *high-entropy* passphrase for use with with Qubes backups.
|
||||
**Caution:** The Qubes backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971). It is *strongly recommended* that users select a *high-entropy* passphrase for use with Qubes backups.
|
||||
|
||||
* [Creating a Backup](#creating-a-backup)
|
||||
* [Restoring from a Backup](#restoring-from-a-backup)
|
||||
|
||||
@ -74,7 +74,7 @@ Customizing Disposable VMs
|
||||
---------------------------------------------------------
|
||||
|
||||
You can change the template used to generate the Disposable VM, and change settings used in the Disposable VM savefile. These changes will be reflected in every new Disposable VM.
|
||||
Full instructions are [here](/doc/disp-vm-customization/)
|
||||
Full instructions are [here](/doc/dispvm-customization/)
|
||||
|
||||
|
||||
Disposable VMs and Local Forensics
|
||||
|
||||
@ -66,6 +66,14 @@ Of course, command line tools are still available for accomplishing various upda
|
||||
sudo yum downgrade package-version
|
||||
~~~
|
||||
|
||||
### How to uninstall a package
|
||||
|
||||
If you've installed a package such as anti-evil-maid, you can remove it with the following command:
|
||||
|
||||
~~~
|
||||
sudo yum remove anti-evil-maid
|
||||
~~~
|
||||
|
||||
### Kernel Upgrade ###
|
||||
|
||||
Install newer kernel. The following example installs kernel 3.19 and was tested on Qubes R3 RC1.
|
||||
|
||||
@ -56,7 +56,7 @@ As long as template's compromise is considered, it doesn't really matter whether
|
||||
|
||||
- But why trusting 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-epxloitable. We certainly do not assume the latter.
|
||||
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?
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ Security considerations for network printers and drivers
|
||||
|
||||
Some printers require 3rd party drivers, typically downloadable from the vendor's website. Such drivers are typically distributed in a form of ready to install RPM packages. However, they are often unsigned, and additionally the downloads are available via HTTP connections only. As a result, installation of such 3rd party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template. (Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
|
||||
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/disposable-vms/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by 3rd party printer drivers).
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by 3rd party printer drivers).
|
||||
|
||||
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
|
||||
|
||||
|
||||
@ -32,16 +32,23 @@ Shutdown the StandaloneVM and you will have extended the size of it's `root.img`
|
||||
|
||||
### Resize a TemplateVM Root Image
|
||||
|
||||
In `dom0` Konsole run the following command (replace the size and path):*Make sure changes in the TemplateVM between reboots didn't exceed 10G.*
|
||||
Shut down the TemplateVM, as well as all VMs based on that template (since they
|
||||
share `root.img`).
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
*Make sure changes in the TemplateVM between reboots didn't exceed 10G.*
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
|
||||
~~~
|
||||
|
||||
Then start Terminal for this TemplateVM and run the following:
|
||||
Then start only the TemplateVM and run the following. Note that if you are
|
||||
resizing the TemplateVM used by, e.g., your NetVM, you may need to disable
|
||||
networking so when the TemplateVM is started, it does not autostart other VMs
|
||||
based on the same `root.img`. Otherwise you will get an error message `Nothing
|
||||
to do!`.
|
||||
|
||||
~~~
|
||||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the TemplateVM and you will have extended the size of it's `root.img`
|
||||
Shutdown the TemplateVM and you will have extended the size of it's `root.img`.
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
---
|
||||
layout: doc
|
||||
title: VPN
|
||||
permalink: /doc/privacy/vpn/
|
||||
permalink: /doc/vpn/
|
||||
redirect_from:
|
||||
- /doc/privacy/vpn/
|
||||
- /en/doc/vpn/
|
||||
- /doc/VPN/
|
||||
- /wiki/VPN/
|
||||
139
developers/code-signing.md
Normal file
139
developers/code-signing.md
Normal file
@ -0,0 +1,139 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Code Signing
|
||||
permalink: /doc/code-signing/
|
||||
---
|
||||
|
||||
Code Signing
|
||||
============
|
||||
|
||||
All contributions to the Qubes OS [source code] must be cryptographically signed
|
||||
by the author's PGP key.
|
||||
|
||||
|
||||
Generating a Key
|
||||
----------------
|
||||
|
||||
(Note: If you already have a PGP key, you may skip this step.)
|
||||
|
||||
Alex Cabal has written an excellent [guide] on creating a PGP keypair.
|
||||
Below, we reproduce just the minimum steps in generating a keypair using GnuPG.
|
||||
Please read Cabal's full guide for further important details.
|
||||
|
||||
~~~
|
||||
$ gpg --gen-key
|
||||
gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc.
|
||||
This is free software: you are free to change and redistribute it.
|
||||
There is NO WARRANTY, to the extent permitted by law.
|
||||
|
||||
Please select what kind of key you want:
|
||||
(1) RSA and RSA (default)
|
||||
(2) DSA and Elgamal
|
||||
(3) DSA (sign only)
|
||||
(4) RSA (sign only)
|
||||
Your selection? 1
|
||||
|
||||
RSA keys may be between 1024 and 4096 bits long.
|
||||
What keysize do you want? (2048) 4096
|
||||
|
||||
Requested keysize is 4096 bits
|
||||
Please specify how long the key should be valid.
|
||||
0 = key does not expire
|
||||
<n> = key expires in n days
|
||||
<n>w = key expires in n weeks
|
||||
<n>m = key expires in n months
|
||||
<n>y = key expires in n years
|
||||
Key is valid for? (0) 0
|
||||
|
||||
Key does not expire at all
|
||||
Is this correct? (y/N) y
|
||||
|
||||
|
||||
You need a user ID to identify your key; the software constructs the user ID
|
||||
from the Real Name, Comment and E-mail Address in this form:
|
||||
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
|
||||
|
||||
Real name: Bilbo Baggins
|
||||
|
||||
E-mail address: bilbo@shire.org
|
||||
|
||||
Comment:
|
||||
You selected this USER-ID:
|
||||
"Bilbo Baggins <bilbo@shire.org>"
|
||||
|
||||
Change (N)ame, (C)omment, (E)-mail or (O)kay/(Q)uit? O
|
||||
|
||||
You need a Passphrase to protect your secret key.
|
||||
|
||||
<type your passphrase>
|
||||
|
||||
gpg: key 488BA441 marked as ultimately trusted
|
||||
public and secret key created and signed.
|
||||
|
||||
gpg: checking the trustdb
|
||||
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
|
||||
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
|
||||
pub 4096R/488BA441 2013-03-13
|
||||
Key fingerprint = B878 1FB6 B187 B94C 3E52 2AFA EB1D B79A 488B A441
|
||||
uid Bilbo Baggins <bilbo@shire.org>
|
||||
sub 4096R/69B0EA85 2013-03-13
|
||||
~~~
|
||||
|
||||
|
||||
Using PGP with Git
|
||||
------------------
|
||||
|
||||
If you're submitting a patch via GitHub (or a similar Git server), please sign
|
||||
your Git commits.
|
||||
|
||||
1. Set up Git to use your key:
|
||||
|
||||
~~~
|
||||
git config --global user.signingkey <KEYID>
|
||||
~~~
|
||||
|
||||
2. Set up Git to sign your commits with your key:
|
||||
|
||||
~~~
|
||||
git config --global commit.gpgsign true
|
||||
~~~
|
||||
|
||||
Alternatively, manually specify when a commit is to be signed:
|
||||
|
||||
~~~
|
||||
commit -S
|
||||
~~~
|
||||
|
||||
3. (Optional) Create signed tags:
|
||||
|
||||
~~~
|
||||
git tag -s <tag_name> -m "<tag_message>"
|
||||
~~~
|
||||
|
||||
You can also create an alias to make this easier:
|
||||
|
||||
~~~
|
||||
stag = "!id=`git rev-parse --verify HEAD`; git tag -s tag_for_${id:0:8} -m \"Tag for commit $id\""
|
||||
~~~
|
||||
|
||||
You may also find it convenient to have an alias for verifying the tag on the
|
||||
latest commit:
|
||||
|
||||
~~~
|
||||
vtag = !git tag -v `git describe`
|
||||
~~~
|
||||
|
||||
|
||||
Using PGP with Email
|
||||
--------------------
|
||||
|
||||
If you're submitting a patch via email (to the developer [mailing list]), simply
|
||||
sign your email with your PGP key. (One good way to do this is with a program
|
||||
like [Enigmail].)
|
||||
|
||||
|
||||
[guide]: https://alexcabal.com/creating-the-perfect-gpg-keypair/
|
||||
[source code]: /doc/source-code/
|
||||
[mailing list]: /doc/mailing-lists/
|
||||
[Enigmail]: https://www.enigmail.net/
|
||||
|
||||
@ -19,6 +19,7 @@ First you should decide what you are interested in (and good in). The Qubes proj
|
||||
- Code audit (e.g. gui-daemon)
|
||||
- New features
|
||||
- Artwork (plymouth themes, KDM themes, installer themes, wallpapers, etc)
|
||||
- [Documentation](/doc/doc-guidelines)
|
||||
|
||||
Perhaps the best starting point is to have a look at the [issues](https://github.com/QubesOS/qubes-issues/issues) to see what are the most urgent tasks to do.
|
||||
|
||||
|
||||
@ -8,8 +8,8 @@ redirect_from:
|
||||
- /doc/DocStyle/
|
||||
---
|
||||
|
||||
Guidelines for Documentation Contributors
|
||||
=========================================
|
||||
Documentation Guidelines
|
||||
========================
|
||||
|
||||
All Qubes OS documentation pages are stored as plain text files in the
|
||||
dedicated [qubes-doc] repository. By cloning and regularly pulling from
|
||||
|
||||
@ -75,7 +75,7 @@ Certainly, it would be insecure to allow AppVM to read/write clipboard of other
|
||||
|
||||
- there is a "qubes clipboard" in dom0 - its contents is stored in a regular file in dom0.
|
||||
- if user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
|
||||
- user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the the local clipboard, and then user can paste its contents to local applications normally.
|
||||
- user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
|
||||
|
||||
This way, user can quickly copy clipboards between AppVMs. This action is fully controlled by the user, it cannot be triggered/forced by any AppVM.
|
||||
|
||||
|
||||
@ -87,7 +87,7 @@ Steps performed by **qvm-revert-template-changes**:
|
||||
3. Replace *snapshot* device-mapper target with *snapshot-merge*, other parameters (chunk size etc) remains untouched. Now kernel starts merging changes stored in *root-cow.img.old* into *root.img*. d-m device can be used normally (if needed).
|
||||
4. Waits for merge completed: *dmsetup status* shows used snapshot blocks – it should be equal to metadata size when completed.
|
||||
5. Replace *snapshot-merge* d-m target back to *snapshot*.
|
||||
6. Cleanup snapshot device (if nobody uses it it the moment).
|
||||
6. Cleanup snapshot device (if nobody uses it at the moment).
|
||||
7. Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
|
||||
|
||||
Snapshot device in AppVM
|
||||
|
||||
@ -30,7 +30,7 @@ Preparing a savefile is done by */usr/lib/qubes/qubes\_prepare\_saved\_domain.sh
|
||||
6. when `qubes_used_mem` key appears, the domain memory is reduced to this amount, to make the savefile smaller.
|
||||
7. APPVM private image is detached
|
||||
8. the domain is saved via *xl save*
|
||||
9. the COW file volatile.img (cow for for root fs and swap) is packed to `saved_cows.tar` archive
|
||||
9. the COW file volatile.img (cow for root fs and swap) is packed to `saved_cows.tar` archive
|
||||
|
||||
*qubes\_prepare\_saved\_domain.sh* script is somehow lowlevel. It is usually called by *qvm-create-default-dvm* script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to *qubes\_prepare\_saved\_domain.sh*, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
|
||||
|
||||
@ -53,4 +53,4 @@ Validating the DisposableVM savefile
|
||||
|
||||
DisposableVM savefile contains references to template rootfs and to COW files. The COW files are restored before each DisposableVM start, so they cannot change. On the other hand, if templateVM is started, the template rootfs will change, and it may not be coherent with the COW files.
|
||||
|
||||
Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necassary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
|
||||
Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
|
||||
|
||||
@ -70,7 +70,7 @@ Additionally, the balance algorithm is tuned so that XEN\_FREE\_MEM\_LEFT (50MB)
|
||||
Whenever *qmemman* is asked to return X megabytes of memory to Xen free pool, the following algorithm (*qmemman\_algo.balloon*) is executed:
|
||||
|
||||
1. find all domains ("donors") whose actual memory is greater than its `prefmem`
|
||||
2. calculate how much memory can be reclaimed by shrinking donors to their `prefmem`. If is is less than X, return error.
|
||||
2. calculate how much memory can be reclaimed by shrinking donors to their `prefmem`. If it is less than X, return error.
|
||||
3. shrink donors, proportionally to their `prefmem`, so that X MB should become free
|
||||
4. wait BALOON\_DELAY (0.1s)
|
||||
5. if some domain have not given back any memory, remove it from the donors list, and go to step 2, unless we already did MAX\_TRIES (20) iterations (then return error).
|
||||
|
||||
@ -313,7 +313,7 @@ steps are taken:
|
||||
* `qrexec-daemon` executes `qrexec-policy`, passing source vmname, target
|
||||
vmname, rpc action, and CID as cmdline arguments
|
||||
* `qrexec-policy` evaluates the policy file. If successful, creates a pair of
|
||||
`qrexec-client` processes, whose stdin/stdout are cross-connencted.
|
||||
`qrexec-client` processes, whose stdin/stdout are cross-connected.
|
||||
* The first `qrexec-client` connects to the src VM, using the `-c ClientID`
|
||||
parameter, which results in not creating a new process, but connecting to
|
||||
the existing process file descriptors (these are the fds of unix socket
|
||||
|
||||
@ -11,16 +11,17 @@ redirect_from:
|
||||
Qubes Source Code Repositories
|
||||
==============================
|
||||
|
||||
All the Qubes code is kept in GIT repositories. We divided the project into several components, each of which has its own separate repository, some of them:
|
||||
All the Qubes code is kept in Git repositories. We have divided the project into
|
||||
several components, each of which has its own separate repository, for example:
|
||||
|
||||
- `core-admin.git` -- the core Qubes infrastructure responsible for VM management, VM templates, fs sharing, etc.
|
||||
- `gui-daemon.git` -- GUI virtualization, Dom0 side.
|
||||
- `gui-agent-linux.git` -- GUI virtualization, Linux VM side.
|
||||
- `linux-template-builder.git` - scripts and other files used to create Qubes templates images.
|
||||
* `core-admin.git` -- The core Qubes infrastructure, responsible for VM
|
||||
management, VM templates, fs sharing, etc.
|
||||
* `gui-daemon.git` -- GUI virtualization, Dom0 side.
|
||||
* `gui-agent-linux.git` -- GUI virtualization, Linux VM side.
|
||||
* `linux-template-builder.git` -- Scripts and other files used to create Qubes
|
||||
template images.
|
||||
|
||||
You can browse the repositories [online on
|
||||
GitHub](https://github.com/QubesOS/). The Qubes official repositories are on
|
||||
this `QubesOS` github account.
|
||||
All of our repositories are available under the [QubesOS GitHub account].
|
||||
|
||||
To clone a repository:
|
||||
|
||||
@ -34,15 +35,47 @@ e.g.:
|
||||
git clone git://github.com/QubesOS/qubes-core-admin.git core-admin
|
||||
~~~
|
||||
|
||||
## Sending a patch
|
||||
To clone **all** of our repositories in a single command:
|
||||
|
||||
If you want to contribute to the project, there are two ways:
|
||||
~~~
|
||||
curl "https://api.github.com/orgs/QubesOS/repos?page=1&per_page=100" | grep -e 'git_url*' | cut -d \" -f 4 | xargs -L1 git clone
|
||||
~~~
|
||||
|
||||
* **Preferred**: Use github [fork & pull requests](https://guides.github.com/activities/forking/)
|
||||
* Sending a patch via the project's mailing list (`git format-patch`).
|
||||
To update (git fetch) **all** of these repositories in a single command:
|
||||
|
||||
~~~
|
||||
find . -mindepth 1 -maxdepth 1 -type d -exec git -C {} fetch --tags --recurse-submodules=on-demand --all \;
|
||||
~~~
|
||||
|
||||
(Alternatively, you can pull instead of just fetching.)
|
||||
|
||||
|
||||
How to Send Patches
|
||||
-------------------
|
||||
|
||||
If you want to contribute code to the project, there are two ways. Whichever
|
||||
method you choose, you must [sign your code] before it can be accepted.
|
||||
|
||||
* **Preferred**: Use GitHub's [fork & pull requests].
|
||||
* Send a patch to our developer [mailing list] (`git format-patch`).
|
||||
|
||||
1. Make all the changes in your working directory, i.e. edit files, move them
|
||||
around (you can use 'git mv' for this), etc.
|
||||
2. Add the changes and commit them (`git add`, `git commit`). Never mix
|
||||
different changes into one commit! Write a good description of the commit.
|
||||
The first line should contain a short summary, and then, if you feel like
|
||||
more explanations are needed, enter an empty new line, and then start the
|
||||
long, detailed description (optional).
|
||||
3. Test your changes NOW: check if RPMs build fine, etc.
|
||||
4. Create the patch using `git format-patch`. This has an advantage over
|
||||
`git diff`, because the former will also include your commit message, your
|
||||
name and email, so that *your* name will be used as a commit's author.
|
||||
5. Send your patch to `qubes-devel`. Start the message subject with
|
||||
`[PATCH]`.
|
||||
|
||||
|
||||
[QubesOS GitHub account]: https://github.com/QubesOS/
|
||||
[sign your code]: /doc/code-signing/
|
||||
[fork & pull requests]: https://guides.github.com/activities/forking/
|
||||
[mailing list]: /doc/mailing-lists/
|
||||
|
||||
1. Make all the changes in your working directory, i.e. edit files, move them around (you can use 'git mv' for this), etc.
|
||||
2. Add the changes and commit them (git add, git commit). Never mix different changes into one commit! Write a good description of the commit. The first line should contain a short summary, and then, if you feel like more explanations are needed, enter an empty new line, and then start the long, detailed description (optional).
|
||||
3. Test your changes NOW: check if RPMs build fine, etc.
|
||||
4. Create the patch using 'git format-patch'. This has an advantage over 'git diff', because the former will also include your commit message, your name and email, so that \*your\* name will be used as a commit's author.
|
||||
5. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string.
|
||||
|
||||
23
doc.md
23
doc.md
@ -13,8 +13,11 @@ redirect_from:
|
||||
|
||||
The Basics
|
||||
----------
|
||||
* [A Tour of Qubes OS](/tour/)
|
||||
* [Getting Started](/getting-started)
|
||||
* [Users' FAQ](/doc/user-faq/)
|
||||
* [Mailing Lists](/doc/mailing-lists/)
|
||||
* [Documentation Guidelines](/doc/doc-guidelines/)
|
||||
* [Further reading: How is Qubes different from...?](http://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html)
|
||||
* [Further reading: Why Qubes is more than a collection of VMs](http://www.invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf)
|
||||
|
||||
@ -85,13 +88,12 @@ Security Guides
|
||||
|
||||
Privacy Guides
|
||||
--------------
|
||||
* [Whonix for privacy & anonymization](/doc/privacy/whonix/)
|
||||
* [Install Whonix in Qubes](/doc/privacy/install-whonix/)
|
||||
* [Updating Whonix in Qubes](/doc/privacy/updating-whonix/)
|
||||
* [Customizing Whonix](/doc/privacy/customizing-whonix/)
|
||||
* [Uninstall Whonix from Qubes](/doc/privacy/uninstall-whonix/)
|
||||
* [How to Install TorVM](/doc/privacy/torvm/)
|
||||
* [How to set up a ProxyVM as a VPN Gateway](/doc/privacy/vpn/)
|
||||
* [Whonix for privacy & anonymization](/doc/whonix/)
|
||||
* [Install Whonix in Qubes](/doc/whonix/install/)
|
||||
* [Updating Whonix in Qubes](/doc/whonix/update/)
|
||||
* [Customizing Whonix](/doc/whonix/customize/)
|
||||
* [Uninstall Whonix from Qubes](/doc/whonix/uninstall/)
|
||||
* [How to Install TorVM](/doc/torvm/)
|
||||
|
||||
|
||||
Configuration Guides
|
||||
@ -138,6 +140,7 @@ Troubleshooting
|
||||
* [Solving problems with Macbook Air 2012](https://groups.google.com/group/qubes-devel/browse_thread/thread/b8b0d819d2a4fc39/d50a72449107ab21#8a9268c09d105e69)
|
||||
* [Getting Sony Vaio Z laptop to work with Qubes](/doc/sony-vaio-tinkering/)
|
||||
* [Getting Lenovo 450 to work with Qubes](/doc/lenovo450-tinkering/)
|
||||
* [Troubleshooting UEFI related problems](/doc/uefi-troubleshooting/)
|
||||
|
||||
|
||||
Reference Pages
|
||||
@ -153,14 +156,14 @@ For Developers
|
||||
--------------
|
||||
* [System Documentation](/doc/system-doc/)
|
||||
* [Developers' FAQ](/doc/devel-faq/)
|
||||
* [How to Contribute to the Qubes OS Project](/doc/contributing/)
|
||||
* [Reporting Security Issues](/security/)
|
||||
* [Reporting Bugs](/doc/reporting-bugs/)
|
||||
* [Source Code](/doc/source-code/)
|
||||
* [How to Contribute to the Qubes OS Project](/doc/contributing/)
|
||||
* [Coding Guidelines](/doc/coding-style/)
|
||||
* [Code Signing](/doc/code-signing/)
|
||||
* [Qubes OS Version Scheme](/doc/version-scheme/)
|
||||
* [Supported Versions](/doc/supported-versions/)
|
||||
* [Coding Guidelines](/doc/coding-style/)
|
||||
* [Documentation Guidelines](/doc/doc-guidelines/)
|
||||
* [Books for Developers](/doc/devel-books/)
|
||||
* [Qubes OS License](/doc/license/)
|
||||
* [Style Guide](/doc/style-guide/)
|
||||
|
||||
@ -11,6 +11,9 @@ Qubes-certified laptops are laptops that have been tested by the Qubes developer
|
||||
|
||||
We aim to partner with a few select computer makers to ensure that Qubes is compatible with them, so that new users have clear path towards getting started with Qubes if they desire. We aim for these makers to be as diverse as possible in terms of geography, cost, and availability.
|
||||
|
||||
Note that we certify only that particular configuration is supported by Qubes
|
||||
OS. We take no responsibility for our partners shipping process - including
|
||||
the hardware will not being modified in any way (malicious or not).
|
||||
|
||||
Purism Librem 13
|
||||
----------------------------
|
||||
|
||||
@ -37,7 +37,7 @@ In order to generate a HCL report in Qubes, simply open a terminal in dom0 (KDE:
|
||||
(Note: If you are working with a new Qubes installation, you may need to update your system in order to download this script.)
|
||||
|
||||
You are encouraged to submit your HCL report for the benefit of further Qubes development and other users.
|
||||
If you would like to submit your HCL report, please send the **HCL Info** `.txt` file to [\`qubes-users@googlegroups.com\`](/doc/mailing-lists/) with the subject `HCL - <your machine model name>`.
|
||||
If you would like to submit your HCL report, please send the **HCL Info** `.yml` file to [\`qubes-users@googlegroups.com\`](/doc/mailing-lists/) with the subject `HCL - <your machine model name>`.
|
||||
Please include any useful information about any Qubes features you may have tested (see the legend below), as well as general machine compatibility (video, networking, sleep, etc.).
|
||||
If you have problems with your hardware try a different kernel in the [Troubleshooting menu](/doc/InstallationGuideR2rc1/#troubleshooting-problems-with-the-installer).
|
||||
Please consider sending the **HCL Support Files** `.cpio.gz` file as well.
|
||||
|
||||
@ -10,17 +10,19 @@ redirect_from:
|
||||
|
||||
# Installation Security Considerations #
|
||||
|
||||
|
||||
## Verifying the Qubes ISO ##
|
||||
|
||||
You should [verify][] the PGP signature on your Qubes ISO before you install
|
||||
You should [verify] the PGP signature on your Qubes ISO before you install
|
||||
from it. However, if the machine on which you attempt the verification process
|
||||
is already compromised, it could falsely claim that a malicious ISO has a good
|
||||
signature. Therefore, in order to be certain that your Qubes ISO is trustworthy,
|
||||
you require a trustworthy machine. But how can you be certain *that* machine is
|
||||
trustworthy? Only by using another trusted machine, and so forth. This is a
|
||||
[classic problem][trusting-trust]. While various [solutions][countering] have
|
||||
been proposed, the point is that each user must ultimately make a choice about
|
||||
whether to trust that a file is non-malicious.
|
||||
[classic problem]. While various [solutions] have been proposed, the point is
|
||||
that each user must ultimately make a choice about whether to trust that a file
|
||||
is non-malicious.
|
||||
|
||||
|
||||
## Choosing an Installation Medium ##
|
||||
|
||||
@ -29,11 +31,12 @@ decided to trust your Qubes ISO. Great! Now you must decide what sort of medium
|
||||
on which to write it so that you can install from it. From a Qubes-specific
|
||||
security perspective, each has certain pros and cons.
|
||||
|
||||
|
||||
### USB Drives ###
|
||||
|
||||
Pros:
|
||||
|
||||
* Works via USB, including with a [USBVM][].
|
||||
* Works via USB, including with a [USB qube].
|
||||
* Non-fixed capacity. (Easy to find one on which the ISO can fit.)
|
||||
|
||||
Cons:
|
||||
@ -45,6 +48,7 @@ Cons:
|
||||
also [compromise the drive][BadUSB]. Installing from a compromised drive
|
||||
could compromise even a brand new Qubes installation.)
|
||||
|
||||
|
||||
### Optical Discs ###
|
||||
|
||||
Pros:
|
||||
@ -71,8 +75,10 @@ Cons:
|
||||
untrusted ISO to dom0 in order to burn it to disc, which leaves only the
|
||||
other two options.)
|
||||
|
||||
[verify]: https://www.qubes-os.org/doc/VerifyingSignatures/
|
||||
[trusting-trust]: http://www.acm.org/classics/sep95/
|
||||
[countering]: http://www.dwheeler.com/trusting-trust/
|
||||
[USBVM]: https://www.qubes-os.org/doc/SecurityGuidelines/#creating-and-using-a-usbvm
|
||||
|
||||
[verify]: /doc/verifying-signatures/
|
||||
[classic problem]: http://www.acm.org/classics/sep95/
|
||||
[solutions]: http://www.dwheeler.com/trusting-trust/
|
||||
[USB qube]: /doc/usb/#creating-and-using-a-usb-qube
|
||||
[BadUSB]: https://srlabs.de/badusb/
|
||||
|
||||
|
||||
@ -17,68 +17,97 @@ redirect_from:
|
||||
---
|
||||
|
||||
Installation Guide
|
||||
========================================
|
||||
|
||||
1. [Hardware Requirements](#hardware-requirements)
|
||||
2. [Download installer ISO](#download-installer-iso)
|
||||
3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick)
|
||||
4. [Upgrading](#upgrading)
|
||||
5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer)
|
||||
6. [Getting Help](#getting-help)
|
||||
==================
|
||||
|
||||
Hardware Requirements
|
||||
---------------------
|
||||
|
||||
Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware.
|
||||
Please see the [system requirements] and [Hardware Compatibility List] pages for
|
||||
more information on required and recommended hardware.
|
||||
|
||||
Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives).
|
||||
**Note:** We don't recommend installing Qubes in a virtual machine! It will
|
||||
likely not work. Please don't send emails asking about it. You can, however,
|
||||
install it on an external USB hard drive and run from it, at least for testing.
|
||||
(Bear in mind, however, that such disks are typically *orders* of magnitude
|
||||
slower than even the slowest internal hard drives). We also have a [live USB]
|
||||
option (currently in alpha).
|
||||
|
||||
Download installer ISO
|
||||
----------------------
|
||||
|
||||
See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/verifying-signatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO:
|
||||
Downloading the ISO
|
||||
-------------------
|
||||
|
||||
gpg -v Qubes-R2-x86_64-DVD.iso.asc
|
||||
See the [downloads] page for ISO downloads. Remember, we have absolutely
|
||||
no control over those servers, so you should be assuming that they might be
|
||||
compromised, or just be serving compromised ISOs because their operators decided
|
||||
so, for whatever reason. Always verify the digital signature on the downloaded
|
||||
ISO. Make sure to read our guide on [verifying signatures] for more info about
|
||||
how to download and verify our PGP keys and verify the downloaded ISO.
|
||||
|
||||
Adjust filename to the version you're installing.
|
||||
|
||||
Burning the ISO onto a DVD or USB stick
|
||||
---------------------------------------
|
||||
Copying the ISO onto the installation medium
|
||||
--------------------------------------------
|
||||
|
||||
Once you verify this is an authentic ISO, you should burn it on a DVD.
|
||||
Once you verify this is an authentic ISO, you should copy it onto the
|
||||
installation medium of your choice, such as a DVD or a USB drive. (Please note
|
||||
that there are important [security considerations] to keep in mind when choosing
|
||||
an installation medium.)
|
||||
|
||||
If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd:
|
||||
If you prefer to use a USB drive, then you just need to copy the ISO onto the
|
||||
USB device, e.g. using `dd`:
|
||||
|
||||
dd if=Qubes-R2-x86_64-DVD.iso of=/dev/sdX
|
||||
dd if=Qubes-R3-x86_64.iso of=/dev/sdX
|
||||
|
||||
Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX)'''**
|
||||
Adjust the filename to the version you're installing. **Be sure to use the
|
||||
correct device as the target in the dd command above (instead of `sdX`).**
|
||||
|
||||
On windows you can use [Rufus](http://rufus.akeo.ie/) tool. Be sure to select "DD image" mode (you need to do that **after** selecting Qubes iso image):
|
||||
On Windows, you can use the [Rufus] tool. Be sure to select "DD image" mode (you
|
||||
need to do that **after** selecting the Qubes ISO):
|
||||
|
||||
<img src="/attachment/wiki/InstallationGuide/rufus-main-boxed.png" height="350">
|
||||
|
||||
Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph.
|
||||
Before proceeding with the installation, you are encouraged to first read all
|
||||
the information on this page. When you're ready, boot your system from the
|
||||
installation source and follow the on-screen instructions. The installer is very
|
||||
simple and asks very few questions. (It's actually easier to install Qubes right
|
||||
now than most other Linux distributions!)
|
||||
|
||||
Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions!
|
||||
The installer loads Xen right at the beginning, so chances are high that if you
|
||||
can see the installer's graphical screen, Qubes will work on your system. :)
|
||||
|
||||
The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :)
|
||||
|
||||
Upgrading
|
||||
---------
|
||||
|
||||
See [release notes](/doc/releases/) of appropriate version.
|
||||
|
||||
For instructions in upgrading an existing installation, please see the **Release
|
||||
Notes** of the version to which you want to upgrade. All of these release notes
|
||||
are available from the main [downloads] page.
|
||||
|
||||
|
||||
Getting Help
|
||||
------------
|
||||
|
||||
- **User manuals are [here](/doc/).** (Strongly recommended!)
|
||||
* We work very hard on making the [documentation] accurate, comprehensive, and
|
||||
useful. We urge you to read it! It may very well contain the answers to your
|
||||
questions. (Since the documentation is a community effort, we'd also greatly
|
||||
appreciate your help in [improving] it!)
|
||||
|
||||
- Developers documentation (normally not needed by users) is [here](/doc/system-doc/)
|
||||
* If you don't find your answer in the documentation, it may be time to consult
|
||||
the [mailing lists], as well as the many other available sources of [help].
|
||||
|
||||
- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below):
|
||||
- [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users)
|
||||
- `qubes-users@googlegroups.com`
|
||||
* Please do not email individual developers (Marek, Joanna, etc.) with
|
||||
questions about installation or other problems. Please send all such
|
||||
questions to the appropriate mailing list.
|
||||
|
||||
|
||||
[system requirements]: /doc/system-requirements/
|
||||
[Hardware Compatibility List]: /hcl/
|
||||
[live USB]: /doc/live-usb/
|
||||
[downloads]: /downloads/
|
||||
[verifying signatures]: /doc/verifying-signatures/
|
||||
[security considerations]: /doc/install-security/
|
||||
[Rufus]: http://rufus.akeo.ie/
|
||||
[documentation]: /doc/
|
||||
[improving]: /doc/doc-guidelines/
|
||||
[mailing lists]: /doc/mailing-lists/
|
||||
[help]: /help/
|
||||
|
||||
- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list.
|
||||
|
||||
@ -20,7 +20,7 @@ We have faced several challenges when making this Live USB edition of Qubes OS,
|
||||
which traditional Linux distros don't have to bother with:
|
||||
|
||||
1. We needed to ensure Xen is properly started when booting the stick. In fact
|
||||
we still don't support UEFI boot for the sitck for this reason, even though
|
||||
we still don't support UEFI boot for the stick for this reason, even though
|
||||
the Fedora liveusb creator we used does support it. Only legacy boot for this
|
||||
version, sorry.
|
||||
2. We discovered that the Fedora liveusb-create does *not* verify signatures on
|
||||
|
||||
@ -21,7 +21,7 @@ Read the [guidelines](/doc/security-guidelines) carefully.
|
||||
One problem is that when you dual or multiboot, even if you are using
|
||||
encryption on your Qubes installation, /boot is still unprotected and
|
||||
could be maliciously modified by the other OS, possibly leading to Qubes
|
||||
itself being maliciously modifed.
|
||||
itself being maliciously modified.
|
||||
|
||||
The other problem is firmware security - for example the other system
|
||||
could infect BIOS firmware, which might enable compromise or spying on
|
||||
@ -177,8 +177,8 @@ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
Troubleshooting
|
||||
----------------------
|
||||
|
||||
If you install Qubes without making any backups beforehand, dont worry.
|
||||
If you didnt overwrite the original partitions, then it is usually
|
||||
If you install Qubes without making any backups beforehand, don't worry.
|
||||
If you didn't overwrite the original partitions, then it is usually
|
||||
possible to recover your old systems relatively easily, as described above.
|
||||
|
||||
If you decided to use a shared /boot and *dont* have backups of your previous
|
||||
|
||||
46
installing/uefi-troubleshooting.md
Normal file
46
installing/uefi-troubleshooting.md
Normal file
@ -0,0 +1,46 @@
|
||||
---
|
||||
layout: doc
|
||||
title: UEFI Troubleshooting
|
||||
permalink: /doc/uefi-troubleshooting/
|
||||
---
|
||||
|
||||
Troubleshooting UEFI related problems
|
||||
========================================
|
||||
|
||||
|
||||
|
||||
Cannot start installation, it hangs after GRUB menu ("Test media and install Qubes OS")
|
||||
---------------------
|
||||
|
||||
There is some [common bug in UEFI implementation](http://xen.markmail.org/message/f6lx2ab4o2fch35r), affecting mostly Lenovo systems, but probably some others too. You can try existing workaround:
|
||||
|
||||
1. In GRUB menu press `e`.
|
||||
2. At the end of `chainloader` line add `/mapbs /noexitboot`.
|
||||
3. Perform installation normally, but not reboot system at the end yet.
|
||||
4. Go to `tty2` (Ctrl-Alt-F2).
|
||||
5. Execute `mount | grep boot/efi` and note device name (first column). It should be something like `/dev/sda1`.
|
||||
6. Execute `efibootmgr -v`, search for `Qubes` entry and note its number (it should be something like `Boot0001` - `0001` is an entry number).
|
||||
7. Replace existing `Qubes` entry with modified one. Replace `XXXX` with entry number from previous step, `/dev/sda` with your disk name and `-p 1` with `/boot/efi` partition number):
|
||||
|
||||
efibootmgr -b XXXX -B
|
||||
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1 "placeholder /mapbs /noexitboot"
|
||||
|
||||
8. Compare new entry with the old one (printed in step 6) - it should only differ in additional options at the end.
|
||||
9. Now you can reboot the system by issuing `reboot` command.
|
||||
|
||||
|
||||
System crash/restart when booting installer
|
||||
-------------------------------------------
|
||||
|
||||
Some Dell systems and probably others have [another bug in UEFI firmware](http://markmail.org/message/amw5336otwhdxi76). And there is another workaround for it:
|
||||
|
||||
|
||||
1. In GRUB menu press `e`.
|
||||
2. At the end of `chainloader` line add `-- efi=attr=uc`.
|
||||
3. Perform installation normally, but not reboot system at the end yet.
|
||||
4. Go to `tty2` (Ctrl-Alt-F2).
|
||||
5. Execute:
|
||||
|
||||
sed -i -e 's/^options=.*/\0 efi=attr=uc' /mnt/sysimage/boot/efi/qubes/xen.cfg
|
||||
|
||||
6. Now you can reboot the system by issuing `reboot` command.
|
||||
@ -11,8 +11,6 @@ redirect_from:
|
||||
Upgrading Qubes R3.0 to R3.1
|
||||
======================================
|
||||
|
||||
**Caution: The procedure to upgrade from R3.0 to R3.1 is experimental!**
|
||||
|
||||
**Before attempting either an in-place upgrade or a clean installation, we
|
||||
strongly recommend that users [back up their systems](/doc/backup-restore/).**
|
||||
|
||||
@ -38,11 +36,11 @@ section should be repeated in **all** the user's Template and Standalone VMs.
|
||||
|
||||
2. Install the `qubes-upgrade-vm` package:
|
||||
|
||||
sudo dnf install --enablerepo=qubes-vm-r3.0-current-testing qubes-upgrade-vm
|
||||
sudo yum install qubes-upgrade-vm
|
||||
|
||||
3. Proceed with a normal upgrade in the template:
|
||||
|
||||
sudo dnf upgrade
|
||||
sudo yum upgrade
|
||||
|
||||
4. Shut down the template VM.
|
||||
|
||||
|
||||
@ -75,3 +75,13 @@ Important Notes
|
||||
TemplateBasedVMs persist in this manner. If you would like to make changes
|
||||
in other directories which *do* persist in this manner, you must make those
|
||||
changes in the parent TemplateVM.
|
||||
|
||||
* Templates are not automatically updated when
|
||||
[updating dom0](/doc/software-update-dom0/). This is by design, since doing
|
||||
so would cause all user modifications to templates to be lost. Instead, you
|
||||
should update your templates
|
||||
[from within each template](/doc/software-update-vm/). If you *do* want to
|
||||
update a template from dom0 (and thereby lose any user modifications in the
|
||||
existing template), you must first uninstall the existing template from dom0:
|
||||
|
||||
$ sudo yum remove qubes-template-fedora-23
|
||||
|
||||
@ -16,27 +16,672 @@ be considered experimental as Qubes developers team use mainly Fedora-based VMs
|
||||
to test new features/updates.
|
||||
|
||||
Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
|
||||
He also provides binary updates for the template, which are signed using this
|
||||
key:
|
||||
|
||||
pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
|
||||
Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
|
||||
uid Olivier MEDOC (Qubes-OS signing key) <o_medoc@yahoo.fr>
|
||||
<br>
|
||||
|
||||
## Instructions ##
|
||||
|
||||
<br>
|
||||
**These are the instructions for Qubes 3.1. They will take you step by step thru the entire process start to finish**
|
||||
|
||||
*Note: Currently there are no binary packages and it must be compiled from source using the instructions below.*
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
#### **1: Create and configure VM to use for template building:** ####
|
||||
|
||||
* The VM should be based on a Fedora template. It's best to use a standalone VM. I created a standalone VM based on
|
||||
the Fedora 23 template. I named the VM “**development**”. These instructions assume a standalone VM based on a Fedora template is being used.
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
* Ensure there is at least 25GB preferably 30GB of free space in the private storage. I made the private storage 30GB to be safe.
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
*Note: Unless otherwise noted, all commands are from within the “development” VM or whatever you named your standalone VM used for building the template.*
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **2: Create GitHub Account (optional):** #####
|
||||
|
||||
* It can be helpful. Creating only a basic account is all that is needed. This will allow you to help, going forward, with the Qubes project. You could be help edit errors in documentation. It can also be of use building other templates.
|
||||
|
||||
* Create user account here https://github.com
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **3: Install necessary packages to 'development' VM for "Qubes Automated Build System":** #####
|
||||
|
||||
* Necessary packages to install:
|
||||
|
||||
* git
|
||||
|
||||
* createrepo
|
||||
|
||||
* rpm-build
|
||||
|
||||
* make
|
||||
|
||||
* rpmdevtools
|
||||
|
||||
* python-sh
|
||||
|
||||
* dailog
|
||||
|
||||
* rpm-sign
|
||||
<br>
|
||||
|
||||
|
||||
Install
|
||||
-------
|
||||
* The tools can usually be installed all together with the following terminal command string:
|
||||
|
||||
Currently we do not ship ready to use binary package. It can be compiled using
|
||||
[this instructions](/doc/building-archlinux-template/).
|
||||
* **$ sudo dnf install git createrepo rpm-build make wget rpmdevtools python-sh dialog rpm-sign**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
Olivier provides binary package build by himself, you can get it for:
|
||||
* Qubes R2 [here](https://groups.google.com/d/msgid/qubes-devel/54CE3FB1.3050708%40yahoo.fr).
|
||||
* Qubes R3 [here](https://groups.google.com/d/msg/qubes-users/RI3KQVEEc30/h5nsNw_SHTQJ)
|
||||
##### **4: Installing the "Qubes Automated Build System":** #####
|
||||
|
||||
* To get the most current build system its best to use marmarek's git repository.
|
||||
|
||||
* $ **git clone https://github.com/marmarek/qubes-builder.git**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* You will now have the Qubes Builder System environment installed in the directory below:
|
||||
|
||||
* **/home/user/qubes-builder**
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **5: Configuring setup script to create builder.conf file:** #####
|
||||
|
||||
* You will be creating the builder.conf file which tells where and what to use. The most automated, and in this case the easiest, way to create this is to use the script that is provided in Qubes Builder. Its named '**setup**'. Before running the script you need to edit one file it uses.
|
||||
|
||||
*In the future this should not be needed once a change is made to the 'setup' script.*
|
||||
|
||||
* Edit the '**qubes-os-master.conf**' which is found in **/home/user/qubes-builder/example-configs** Use the text editor of your choice.
|
||||
|
||||
* **$ cd /home/user/qubes-builder/example-config/**
|
||||
|
||||
* **$ nano -W qubes-os-master.conf** or **$ gedit qubes-os-master.conf** or etc….
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
* Go to the first line containing '**DIST_VM ?= fc23**' it will be preceeded by line '**DIST_DOM0 ?= fc20**'. Remove '**fc23**' or whatever is listed there leaving only '**DIST_VM ?=**'. Then save the file and close the text editor.
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **6: Run the 'setup' script to build the builder.conf file** #####
|
||||
|
||||
* Run the 'setup' script located in '**/home/user/qubes-builder/**' Make sure you are in directory '**qubes-builder**'
|
||||
|
||||
* **$ cd /home/user/qubes-builder/**
|
||||
|
||||
* **$ ./setup**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
* First screen will ask you to import 'Qubes-Master-Signing-key.asc'. The 'setup' script not only downloads but confirms the key to that of the key on Qubes-OS website.
|
||||
|
||||
* Select '**YES**'
|
||||
* Select '**OK**' Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* Next screen will ask you to import Marek Marczykowski-Goracki (Qubes OS signing key). Again 'setup' will confirm this key to the fingerprint.
|
||||
|
||||
* Select '**YES**'
|
||||
* Select '**OK**' Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* This screen will give you the choice of which Qubes Release to build the template for.
|
||||
|
||||
* Select '**Qubes Release 3.1**'
|
||||
* Select '**OK**' Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* Screen "**Choose Repos To Use To Build Packages**"
|
||||
|
||||
* Select 'marmarek/qubes- Unstable-Bleeding Edge for Development'
|
||||
* Select '**OK**' Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* Screen '**Builder Plugin Selection**' will give choices of builder plugins to use for the build.
|
||||
|
||||
* Deselect '**Fedora**'
|
||||
|
||||
* Deselect '**mgnt_salt**'
|
||||
|
||||
* Select '**archlinux**'
|
||||
|
||||
* Select '**OK**' Press **Enter**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* Screen '**Get Resources**' wants to download additional packages needed for the choosen plugin/s.
|
||||
|
||||
* Select '**OK**' Prss '**Enter**'
|
||||
|
||||
* Upon completion you will get choose '**OK**' to proceed to the next screen
|
||||
|
||||
* Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* Screen '**Template Distribution Selection**' allows you to choose the actual template/s you wish to build.
|
||||
|
||||
* Scroll Down to the very bottom (it is off the screen at first)
|
||||
|
||||
* Select '**archlinux**'
|
||||
|
||||
* Select '**OK**' Press '**Enter**'
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
*Note: 'Setup' will close and will output the text of the created build.conf file as well as the needed **make** commands to build the template*
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **7: Install all the dependencies:** #####
|
||||
|
||||
*Note: make sure you are in the “qubes-builder” directory to run the following cmds*
|
||||
|
||||
* **$ make install-deps**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **8: Get all the require sources for the build: (Note: this may take some time)** #####
|
||||
|
||||
* **$ make get-sources**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **9: Make all the require Qubes Components:** #####
|
||||
|
||||
* **Note:** You can run a single command to build all the Qubes components or you can run them each individually.
|
||||
Both ways below:
|
||||
|
||||
* Single command to build all Qubes components together: (this command can take a long time to process depending of your pc proccessing power)
|
||||
|
||||
* **$ make qubes-vm**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
* These are the indivual component 'make' commands:
|
||||
|
||||
* **$ make vmm-xen-vm**
|
||||
|
||||
* **$ make core-vchan-xen-vm**
|
||||
|
||||
* **$ make core-qubesdb-vm**
|
||||
|
||||
* **$ make linux-utils-vm**
|
||||
|
||||
* **$ make core-agent-linux-vm**
|
||||
|
||||
* **$ make gui-common-vm**
|
||||
|
||||
* **$ make gui-agent-linux-vm**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
##### **10: Make the actual Archlinux template:** #####
|
||||
|
||||
Known issues
|
||||
------------
|
||||
* **$ make template**
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
If you want to help in improving the template, feel free to [contribute](/doc/contributing/).
|
||||
|
||||
##### **11: Transfer Template into Dom0** #####
|
||||
|
||||
* You need to ensure these two files are in the '**noarch**' directory
|
||||
|
||||
* **$ cd /home/user/qubes-builder/qubes-src/linux-template-builder/rpm/**
|
||||
|
||||
* **$ ls** *(confirm the below two files are there)*
|
||||
|
||||
* **install-templates.sh** (script to install template in dom0)
|
||||
|
||||
* **$ cd noarch**
|
||||
|
||||
* **$ ls**
|
||||
|
||||
* **qubes-template-archlinux-X.X.X-XXXXXXXXXXXX.noarch.rpm** (this is the template package 'X' replaces version and build digits)
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
* **Transfer the install-templates.sh script file into Dom0**
|
||||
*Note: as there is not a typical file transfer method for Dom0, for security reasons, this less than simple transfer function has to be used*
|
||||
|
||||
* Swtich to Domo and open a terminal window.
|
||||
|
||||
**Note:** Take care when entering these cmd strings. They are very long and have a number of characters that are easy to mix '**-**' vs '**.**' '**<u>T</u>emplates** (correct) vs **<u>t</u>emplates** (wrong) or **Template_**'(also wrong) This script will also take care of transfering the actual template.rpm to Dom0 as well.
|
||||
|
||||
|
||||
* **$ cd /**
|
||||
|
||||
* **$ sudo qvm-run --pass-io development 'cat /home/user/qubes-builder/qubes-src/linux-template-builder/rpm/install-templates.sh' > install-templates.sh**
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **If everything went correct there should be a Archlinux template listed in your Qubes VM Manager** #####
|
||||
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
---------------
|
||||
|
||||
## **Package Manager Proxy Setup Section** ##
|
||||
|
||||
|
||||
One last thing to setup to have a "PROPERLY" functioning archlinux template.
|
||||
|
||||
Archlinux package manager Pacman is a fine package mangers except that we could not find a way to configure it to use the Qubes Update Proxy Service (QUPS) that would comply with Qubes QUPS usage policy.
|
||||
|
||||
*If someone does find a way please post to the Qubes-Users or Devel google groups mailing list.*
|
||||
|
||||
Powerpill is a full Pacman wrapper that not only give easy proxy configuration but further offers numerous other advantages.
|
||||
|
||||
Please check out:
|
||||
|
||||
[Archlinux Powerpill](https://wiki.archlinux.org/index.php/powerpill)
|
||||
|
||||
[XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)
|
||||
|
||||
|
||||
**Important Note:** Until Powerpill is configured you will have to open network access to the template to get the initial packages etc downloaded. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services thru the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **1: Editing Pacman's configuration file (pacman.conf)** #####
|
||||
|
||||
* Open archlinux terminal app
|
||||
|
||||
* edit /etc/pacman.conf
|
||||
|
||||
* **$ sudo nano -w /etc/pacman.conf**
|
||||
|
||||
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
|
||||
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
# /etc/pacman.conf
|
||||
#
|
||||
# See the pacman.conf(5) manpage for option and repository directives
|
||||
|
||||
#
|
||||
# GENERAL OPTIONS
|
||||
#
|
||||
[options]
|
||||
# The following paths are commented out with their default values listed.
|
||||
# If you wish to use different paths, uncomment and update the paths.
|
||||
# RootDir = /
|
||||
# DBPath = /var/lib/pacman/
|
||||
# CacheDir = /var/cache/pacman/pkg/
|
||||
# LogFile = /var/log/pacman.log
|
||||
GPGDir = /etc/pacman.d/gnupg/
|
||||
HoldPkg = pacman glibc
|
||||
# XferCommand = /usr/bin/curl -C - -f %u > %o
|
||||
# XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
|
||||
# CleanMethod = KeepInstalled
|
||||
# UseDelta = 0.7
|
||||
Architecture = auto
|
||||
|
||||
|
||||
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
|
||||
# IgnorePkg =
|
||||
# IgnoreGroup =
|
||||
# NoUpgrade =
|
||||
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
|
||||
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
|
||||
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
|
||||
# NoExtract =
|
||||
|
||||
# Misc options
|
||||
# UseSyslog
|
||||
# Color
|
||||
# TotalDownload
|
||||
CheckSpace
|
||||
# VerbosePkgLists
|
||||
|
||||
# By default, pacman accepts packages signed by keys that its local keyring
|
||||
# trusts (see pacman-key and its man page), as well as unsigned packages.
|
||||
|
||||
**Edited Line:** `# SigLevel = Required DatabaseOptional`
|
||||
|
||||
LocalFileSigLevel = Optional
|
||||
# RemoteFileSigLevel = Required
|
||||
|
||||
# NOTE: You must run `pacman-key --init` before first using pacman; the local
|
||||
# keyring can then be populated with the keys of all official Arch Linux
|
||||
# packagers with `pacman-key --populate archlinux`.
|
||||
|
||||
#
|
||||
# REPOSITORIES
|
||||
# - can be defined here or included from another file
|
||||
# - pacman will search repositories in the order defined here
|
||||
# - local/custom mirrors can be added here or in separate files
|
||||
# - repositories listed first will take precedence when packages
|
||||
# have identical names, regardless of version number
|
||||
# - URLs will have $repo replaced by the name of the current repo
|
||||
# - URLs will have $arch replaced by the name of the architecture
|
||||
#
|
||||
# Repository entries are of the format:
|
||||
# [repo-name]
|
||||
# Server = ServerName
|
||||
# Include = IncludePath
|
||||
#
|
||||
# The header [repo-name] is crucial - it must be present and
|
||||
# uncommented to enable the repo.
|
||||
#
|
||||
|
||||
# The testing repositories are disabled by default. To enable, uncomment the
|
||||
# repo name header and Include lines. You can add preferred servers immediately
|
||||
# after the header, and they will be used before the default mirrors.
|
||||
|
||||
# [testing]
|
||||
# SigLevel = PackageRequired
|
||||
# Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
[core]
|
||||
|
||||
**Edited Line:** `SigLevel = PackageRequired`
|
||||
|
||||
Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
[extra]
|
||||
|
||||
**Edited Line:** `SigLevel = PackageRequired`
|
||||
|
||||
Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
# [community-testing]
|
||||
# SigLevel = PackageRequired
|
||||
# Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
[community]
|
||||
|
||||
**Edited Line:** `SigLevel = PackageRequired`
|
||||
|
||||
Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
# If you want to run 32 bit applications on your x86_64 system,
|
||||
# enable the multilib repositories as required here.
|
||||
|
||||
# [multilib-testing]
|
||||
# Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
# [multilib]
|
||||
# Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
# An example of a custom package repository. See the pacman manpage for
|
||||
# tips on creating your own repositories.
|
||||
# [custom]
|
||||
# SigLevel = Optional TrustAll
|
||||
# Server = file:///home/custompkgs
|
||||
|
||||
[multilib]
|
||||
|
||||
**Edited Line:** `SigLevel = PackageRequired`
|
||||
|
||||
Include = /etc/pacman.d/mirrorlist
|
||||
|
||||
**Edited Line:** `# [qubes]`
|
||||
|
||||
**Edited Line:** `# Server = http://olivier.medoc.free.fr/archlinux/pkgs/`
|
||||
|
||||
**Add Section Below:**
|
||||
|
||||
[xyne-x86_64]
|
||||
# A repo for Xyne's own projects: http://xyne.archlinux.ca/projects/
|
||||
# Packages for the "x86_64" architecture.
|
||||
# Added for PowerPill app
|
||||
# Note that this includes all packages in [xyne-any].
|
||||
SigLevel = Required
|
||||
Server = http://xyne.archlinux.ca/repos/xyne
|
||||
|
||||
----------
|
||||
|
||||
<br>
|
||||
|
||||
##### **2: Setting Up GPG** (needs network access) #####
|
||||
|
||||
* Initialize GPG Keyring
|
||||
|
||||
* **$ sudo pacman-key --init**
|
||||
|
||||
* Populate the keyring with Archlinux master keys
|
||||
|
||||
* **$ sudo pacman-key --populate archlinux**
|
||||
|
||||
* Confirm keys with those at [Archlinux Master Keys](https://www.archlinux.org/master-keys/)
|
||||
|
||||
* For more information on Pacman key signing: [Pacman Package Key Signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **3: Install Powerpill (Pacman wrapper)** (needs network access) #####
|
||||
|
||||
* **$ sudo pacman -S powerpill**
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **4: Install Reflector** (needs network access) #####
|
||||
|
||||
*Note: It scripts mirror updating. Grabbing the most up to date gen mirror list. It ranks them by most recently sync'd. Then ranks them on fastest speed. Also can be used by Powerpill config to allow a once stop conf file for all if so wanted.*
|
||||
|
||||
* **$ sudo pacman -S reflector**
|
||||
|
||||
|
||||
Note: You can combine package downloads: **$ sudo pacman -S powerpill reflector**
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **5: Backup mirrorlist prior to first running Reflector.** #####
|
||||
|
||||
Note: For info on Reflector and its configs: [Reflector](https://wiki.archlinux.org/index.php/Reflector)
|
||||
|
||||
* **$ sudo cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bkup**
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **6: Setup mirrolist with Reflector** (needs network access)** #####
|
||||
|
||||
*Note: Look at the Reflector page to decide what filter and argument string you wish to run. Below is a default string that will work for most all to setup a working basic mirrorlist.
|
||||
|
||||
*Look to Reflector pages or --help for more info on args and filters.*
|
||||
|
||||
* **$ sudo reflector --verbose -l 5 --sort rate --save /etc/pacman.d/mirrorlist**
|
||||
|
||||
* The above ranks all the most up to date and sorts for the 5 fastest
|
||||
|
||||
* You can confirm the new list by opening the newly created mirrorlist.
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
##### **7: Configure Powerpill configuration file to use Qubes Proxy Service** #####
|
||||
|
||||
* Qubes Proxy Address: **10.137.255.254:8082**
|
||||
|
||||
* Edit **powerpill.json** (powerpill config file)
|
||||
|
||||
* **$ sudo nano -w /etc/powerpill/powerpill.json**
|
||||
|
||||
* Add line '**--all-proxy=10.137.255.254:8082**' at the bottom of the list under the **"aria2"** section under the **"args"** line. Example below:
|
||||
|
||||
<br>
|
||||
|
||||
{
|
||||
"aria2": {
|
||||
"args": [
|
||||
"--allow-overwrite=true",
|
||||
"--always-resume=false",
|
||||
"--auto-file-renaming=false",
|
||||
"--check-integrity=true",
|
||||
"--conditional-get=true",
|
||||
"--continue=true",
|
||||
"--file-allocation=none",
|
||||
"--log-level=error",
|
||||
"--max-concurrent-downloads=100",
|
||||
"--max-connection-per-server=5",
|
||||
"--min-split-size=5M",
|
||||
"--remote-time=true",
|
||||
"--show-console-readout=true",
|
||||
"--all-proxy=10.137.255.254:8082"
|
||||
],
|
||||
"path": "/usr/bin/aria2c"
|
||||
},
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
##### **8: Test Powerpill Configuration** #####
|
||||
|
||||
*Note: Powerpill uses and passes the same syntax as pacman*
|
||||
|
||||
* Configure Archlinux Template to only use the Qubes Proxy Update Service
|
||||
* In the Qubes VM Manager under Archlinux FW tab make sure only the access check box for update proxy is on. All others should be set to deny.
|
||||
|
||||
* **$ sudo powerpill -Syu**
|
||||
|
||||
* You should get a similar output as below:
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
**Remember you must open up network access anytime you wish to run the Reflector script to update the mirrorlist. This page will be updated when/if this situation changes.**
|
||||
|
||||
|
||||
### **If the above checks out, you can start using your new Archlinux Template** ###
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
#### **Known Issues:** ####
|
||||
|
||||
* If there is an Arch upgrade of Pulse Audio it will require rebuilding and installing Qubes component: gui-agent-linux
|
||||
|
||||
* There May also be a similar issue of dependencies with Xorg.
|
||||
|
||||
* Upgrade Relfector functionality to allow its use thru the QUPS
|
||||
|
||||
* Pacman functionality changes and allows it to be directly configured to work thru QUPS.
|
||||
|
||||
<br>
|
||||
|
||||
#### **Qubes Mailing List Threads on the Archlinux build process:** ####
|
||||
|
||||
* [Qubes-Devel](https://groups.google.com/forum/#!forum/qubes-devel): [Qubes Builder failed Archlinux repository is missing](https://groups.google.com/forum/#!topic/qubes-devel/tIFkS-rPVx8)
|
||||
|
||||
* [Qubes-Users](https://groups.google.com/forum/#!forum/qubes-users): [Trying to compile archlinux template](https://groups.google.com/forum/#!topic/qubes-users/7wuwr3LgkQQ)
|
||||
|
||||
<br>
|
||||
|
||||
#### **Want to contribute?** ####
|
||||
|
||||
* [How can I contribute to the Qubes Project?](/doc/contributing/)
|
||||
|
||||
* [Guidelines for Documentation Contributors](doc/doc-guidelines/)
|
||||
|
||||
<br>
|
||||
|
||||
@ -20,4 +20,4 @@ Whonix template(s) are another Qubes community contribution. Currently Whonix ac
|
||||
|
||||
### Installation & Details
|
||||
|
||||
To learn more and for installation instructions, read our privacy guide: [Whonix for privacy & anonymization](/doc/privacy/whonix/)
|
||||
To learn more and for installation instructions, read our privacy guide: [Whonix for privacy & anonymization](/doc/whonix/)
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
---
|
||||
layout: doc
|
||||
title: TorVM
|
||||
permalink: /doc/privacy/torvm/
|
||||
permalink: /doc/torvm/
|
||||
redirect_from:
|
||||
- /doc/privacy/torvm/
|
||||
- /en/doc/torvm/
|
||||
- /doc/TorVM/
|
||||
- /doc/UserDoc/TorVM/
|
||||
@ -17,8 +18,10 @@ Known issues:
|
||||
Qubes TorVM (qubes-tor)
|
||||
==========================
|
||||
|
||||
Qubes TorVM is a ProxyVM service that provides torified networking to all its
|
||||
clients.
|
||||
Qubes TorVM is a deprecated ProxyVM service that provides torified networking to
|
||||
all its clients. **If you are interested in TorVM, you will find the
|
||||
[Whonix implementation in Qubes](https://www.qubes-os.org/doc/privacy/whonix/) a
|
||||
more usable and robust solution for creating a torifying traffic proxy.**
|
||||
|
||||
By default, any AppVM using the TorVM as its NetVM will be fully torified, so
|
||||
even applications that are not Tor aware will be unable to access the outside
|
||||
@ -32,8 +35,6 @@ All non-DNS UDP and IPv6 traffic is silently dropped.
|
||||
|
||||
See [this article](http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html) for a description of the concept, architecture, and the original implementation.
|
||||
|
||||
**If you are interested TorVM, you may find the [Whonix gateway template](https://www.qubes-os.org/doc/templates/whonix/) in Qubes a more usable and robust solution for creating a torifying traffic proxy.**
|
||||
|
||||
## Warning + Disclaimer
|
||||
|
||||
1. Qubes TorVM is produced independently from the Tor(R) anonymity software and
|
||||
@ -188,7 +189,7 @@ access with different stream isolation settings:
|
||||
* Port 9050 - Isolates by SOCKS Auth and client address only
|
||||
Each AppVM gets its own circuit, and each app using a unique SOCKS
|
||||
user/pass gets its own circuit
|
||||
* Port 9049 - Isolates client + estination port, address, and by SOCKS Auth
|
||||
* Port 9049 - Isolates client + destination port, address, and by SOCKS Auth
|
||||
Same as default settings listed above, but additionally traffic
|
||||
is isolated based on destination port and destination address.
|
||||
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Customizing Whonix
|
||||
permalink: /doc/privacy/customizing-whonix/
|
||||
permalink: /doc/whonix/customize/
|
||||
redirect_from: /doc/privacy/customizing-whonix/
|
||||
---
|
||||
|
||||
Customizing Whonix
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Install Whonix in Qubes
|
||||
permalink: /doc/privacy/install-whonix/
|
||||
permalink: /doc/whonix/install/
|
||||
redirect_from: /doc/privacy/install-whonix/
|
||||
---
|
||||
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Uninstall Whonix from Qubes
|
||||
permalink: /doc/privacy/uninstall-whonix/
|
||||
permalink: /doc/whonix/uninstall/
|
||||
redirect_from: /doc/privacy/uninstall-whonix/
|
||||
---
|
||||
|
||||
Uninstall Whonix from Qubes
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Updating Whonix in Qubes
|
||||
permalink: /doc/privacy/updating-whonix/
|
||||
permalink: /doc/whonix/update/
|
||||
redirect_from: /doc/privacy/updating-whonix/
|
||||
---
|
||||
|
||||
Updating Whonix in Qubes
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Whonix for privacy & anonymizations
|
||||
permalink: /doc/privacy/whonix/
|
||||
permalink: /doc/whonix/
|
||||
redirect_from: /doc/privacy/whonix/
|
||||
---
|
||||
|
||||
Whonix for Privacy & Anonymity
|
||||
@ -15,13 +16,13 @@ To improve your privacy & anonymity on the internet, you can install the [Whonix
|
||||
|
||||
To install Whonix, you must have a working Qubes machine already.
|
||||
|
||||
* [Install Whonix in Qubes](/doc/privacy/install-whonix/)
|
||||
* [Updating Whonix in Qubes](/doc/privacy/updating-whonix/)
|
||||
* [Install Whonix in Qubes](/doc/whonix/install/)
|
||||
* [Updating Whonix in Qubes](/doc/whonix/update/)
|
||||
|
||||
### Customizing & Uninstalling Whonix
|
||||
|
||||
* [Customizing Whonix](/doc/privacy/customizing-whonix/)
|
||||
* [Uninstall Whonix from Qubes](/doc/privacy/uninstall-whonix/)
|
||||
* [Customizing Whonix](/doc/whonix/customize/)
|
||||
* [Uninstall Whonix from Qubes](/doc/whonix/uninstall/)
|
||||
|
||||
*The following links are on Whonix's website and are technical.*
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ Date
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
qvm-run vmname command [aguments]
|
||||
qvm-run vmname command [arguments]
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
@ -26,4 +26,4 @@ article td, article th {
|
||||
| 12 Jan 2016 | 3.1-rc2 release |
|
||||
| 26 Jan 2016 | decide whether 3.1-rc2 is the final 3.1 |
|
||||
| 9 Feb 2016 | current-testing freeze before 3.1-rc3 |
|
||||
| 16 Feb 2016 | 3-1-rc3 release |
|
||||
| <strike>16 Feb 2016</strike><br/>23 Feb 2016 | 3.1-rc3 release |
|
||||
|
||||
@ -45,7 +45,7 @@ supported.
|
||||
| Release 3.2 | TBA | TBA |
|
||||
| Release 4.0 | TBA | TBA |
|
||||
|
||||
\* Denotes versions for which we have pubished the packages but have not done
|
||||
\* Denotes versions for which we have published the packages but have not done
|
||||
extensive testing.
|
||||
|
||||
[r3.1-schedule]: /doc/releases/3.1/schedule/
|
||||
|
||||
@ -54,7 +54,7 @@ SMS:
|
||||
over to government agencies.)
|
||||
|
||||
* Using `oathtool` in a dedicated, network-isolated Qubes VM allows us to
|
||||
achieve a unqiue combination of security and convenience. The strong isolation
|
||||
achieve a unique combination of security and convenience. The strong isolation
|
||||
Qubes provides allows us to reap the full security benefits of MFA, while
|
||||
virtualization frees us from having to worry about finding and handling a
|
||||
second physical device.
|
||||
|
||||
@ -13,7 +13,7 @@ Using YubiKey to Qubes authentication
|
||||
You can use YubiKey to enhance Qubes user authentication, for example to mitigate
|
||||
risk of snooping the password. This can also slightly improve security when you have [USB keyboard](https://github.com/marmarek/qubes-app-linux-input-proxy).
|
||||
|
||||
There (at least) two possible configurations: using OTP mode and using challenge-reponse mode.
|
||||
There (at least) two possible configurations: using OTP mode and using challenge-response mode.
|
||||
|
||||
OTP mode
|
||||
--------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user