mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Merge remote-tracking branch 'origin/pr/62'
This commit is contained in:
Marek Marczykowski-Górecki
commit
b079a3b705
@ -1,120 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Getting Started
|
||||
permalink: /doc/getting-started/
|
||||
redirect_from:
|
||||
- /en/doc/getting-started/
|
||||
- /doc/GettingStarted/
|
||||
- /wiki/GettingStarted/
|
||||
---
|
||||
|
||||
Getting Started with Qubes OS
|
||||
=============================
|
||||
|
||||
Note: This guide assumes that you've just installed Qubes for the first time. The installation guide for your Qubes release can be found on the [Downloads](/downloads/) page.
|
||||
|
||||
Now that you've installed Qubes, let's cover some basic concepts.
|
||||
|
||||
AppVMs (Domains) and TemplateVMs
|
||||
--------------------------------
|
||||
|
||||
In Qubes, you run all your programs in **domains**. Domains are also called **AppVMs** because they're implemented as lightweight virtual machines (VMs). Not every app runs in its own VM. (That would be a big waste of resources!) Instead, each VM represents a *security domain* (e.g., "work," "personal," "banking," etc.). Each domain is based, by default, on a single, common **TemplateVM** (but you can create as many as you'd like). This means that when you create a new AppVM, you don't copy the whole root filesystem needed for this AppVM to work (which would include copying all the programs). Instead, each AppVM *shares* the root filesystem with its respective TemplateVM. An AppVM has read-only access to the filesystem of the Template on which it's based, so an AppVM cannot modify a TemplateVM in any way. This is important, as it means that if an AppVM is ever compromised, the TemplateVM on which it's based (and any other AppVMs based on that TemplateVM) will still be safe. This means that creating a large number of domains is cheap: Each one needs only as much disk space as is necessary to store its private files (e.g., the "home" folder).
|
||||
|
||||
If you've installed Qubes using the default options, a few domains have already been created for you:
|
||||
|
||||
- work
|
||||
- personal
|
||||
- untrusted
|
||||
|
||||
Each domain, apart from having a distinct name, is also assigned a **label**, which is one of several pre-defined colors. The trusted window manager uses these colors in order to draw window decorations (color frames) around the windows of applications running in each domain. These allow you to quickly and easily identify the trust level of a given window at a glance. It's totally up to you how you'd like to interpret these colors. Personally, I find it natural to associate red with that which is untrusted and dangerous (the “red light” -- stop! danger!), green with that which is safe and trusted, and yellow and orange with things in the middle. I've also extended this scheme to include blue and black, which I interpret as indicating progressively more trusted domains than green, with black being ultimately trusted.
|
||||
|
||||
|
||||
|
||||
In addition to AppVMs and TemplateVMs, there's one special domain called "dom0," which is where the Desktop Manager runs. This is where you log in to the system. Dom0 is more trusted than any other domain (including TemplateVMs and black-labeled domains). If dom0 were ever compromised, it would be Game Over<sup>TM</sup>. (The entire system would effectively be compromised.) Due to its overarching importance, dom0 has no network connectivity and is used only for running the Window and Desktop Managers. Dom0 shouldn't be used for anything else. In particular, [you should never run user applications in dom0](/doc/security-guidelines/#dom0-precautions). (That's what your AppVMs are for!)
|
||||
|
||||
Qubes VM Manager and Command Line Tools
|
||||
---------------------------------------
|
||||
|
||||
All aspects of the Qubes system can be controlled using command line tools run under a dom0 console. To open a console window in dom0, either go to Start-\>System Tools-\>Konsole or press Alt-F2 and type `konsole`.
|
||||
|
||||
Various command line tools are described as part of this guide, and the whole reference can be found [here](/doc/dom0-tools/).
|
||||
|
||||
|
||||
|
||||
Alternatively, you can use a rather intuitive GUI tool called **Qubes VM Manager**. It supports most of the functionality that command line tools provide. The Qubes VM Manager starts and opens automatically when Qubes starts up, but you can also start it by going to Start-\>System Tools-\>Qubes Manager. Once the Qubes VM Manager is running, you can open the window at any time by clicking on the Qubes tray icon, which typically resides in the bottom-right corner of the screen.
|
||||
|
||||
|
||||
|
||||
Starting Apps in Domains
|
||||
------------------------
|
||||
|
||||
Apps can be started either by using the shortcuts in the Desktop Manager's menu or by using the command line (i.e., a console running in dom0).
|
||||
|
||||
You can start apps directly from the start menu. Each domain has its own menu directory under the scheme **Domain: \<name\>**. After navigating into one of these directories, simply click on the application you'd like to start:
|
||||
|
||||
 
|
||||
|
||||
By default, each domain's menu contains only a few shortcuts. If you'd like to add more, simply click **Add more shortcuts...**, select the desired applications, and click **OK**. You can also add shortcuts manually. (This is sometimes necessary if the desired application doesn't show up in the Qubes VM Manager window.) To do this in KDE, right-click on the **Start** button and click **Menu Editor**. Click the domain directory in which you'd like the menu to appear, click **New Item**, enter its name as **\<domain name\>: \<app name\>**, and provide the command for starting the app (see below). Then click **Save** and wait approximately 15 seconds for the changes to propagate to the KDE menu.
|
||||
|
||||
To start apps from the console in dom0, type:
|
||||
|
||||
qvm-run -a <domain> "<app name> [arguments]"
|
||||
|
||||
e.g.:
|
||||
|
||||
qvm-run -a untrusted firefox
|
||||
|
||||
Adding, Removing, and Listing Domains
|
||||
-------------------------------------
|
||||
|
||||
Domains can easily be added and removed by clicking on the **Add** and **Remove** buttons in the Qubes VM Manager.
|
||||
|
||||
Domains can also be added, removed, and listed from command line (i.e., a console running in dom0) using the following tools:
|
||||
|
||||
- `qvm-create`
|
||||
- `qvm-remove`
|
||||
- `qvm-ls`
|
||||
|
||||
How Many Domains Do I Need?
|
||||
---------------------------
|
||||
|
||||
That's a great question, but there's no one-size-fits-all answer. It depends on the structure of your digital life, and this is at least a little different for everyone. If you plan on using your system for work, then it also depends on what kind of job you do.
|
||||
|
||||
It's a good idea to start out with the three domains created automatically by the installer: work, personal, and untrusted. Then, if and when you start to feel that some activity just doesn't fit into any of your existing domains, you can easily create a new domain for it. You'll also be able to easily copy any files you need to the newly created domain, as explained [here](/doc/copying-files/).
|
||||
|
||||
More paranoid people might find it worthwhile to read [this article](http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html), which describes how one of the Qubes authors partitions her digital life into security domains.
|
||||
|
||||
Full Screen Domains
|
||||
-------------------
|
||||
|
||||
By default, Qubes doesn't allow any application window to occupy the entire screen such that its window name (which includes the name of the domain to which it belongs) and colored window border are no longer visible. This is a security precaution designed to prevent a situation in which an application which has been allowed to enter full screen mode begins to emulate the entire Qubes system. We want it to be the case that the user is always able to identify which domain is displaying any given window. Otherwise, a compromised domain which is able to occupy the entire screen could trick the user into thinking that she is interacting with a variety of different domains (including dom0), when in fact she is interacting with only a single, compromised domain pretending to be the whole system.
|
||||
|
||||
However, if the user makes use of an "expose-like" desktop switcher, such as the "Desktop Grid" effect that is enabled by default under KDE (default activation command: Ctrl-F8), then we can safely allow domains to enter full screen mode, as we have assurance that we can always "preempt" them by hitting the magic key combination (e.g., Ctrl-F8), which will be consumed by the trusted window manager and not passed down to the fullscreen AppVM. This means that the AppVM has no way of effectively "faking" the fullscreen view of the system, as the user can easily identify it as "just another AppVM." Theoretically, this could be achieved even with primitive Alt-Tab like switching, which should be available on simpler Window Managers (such as Xfce4, which we also support as an alternative dom0 Desktop Environment), but this might be less obvious to the user.
|
||||
|
||||
To allow domains to enter full screen mode, one should edit the `/etc/qubes/guid.conf` file in dom0.
|
||||
|
||||
E.g. to allow all domains to enter full screen mode, set `allow_fullscreen` flag to `true` in the `global` section:
|
||||
|
||||
global: {
|
||||
# default values
|
||||
allow_fullscreen = false;
|
||||
#allow_utf8_titles = false;
|
||||
#secure_copy_sequence = "Ctrl-Shift-c";
|
||||
#secure_paste_sequence = "Ctrl-Shift-v";
|
||||
#windows_count_limit = 500;
|
||||
};
|
||||
|
||||
To allow only select AppVMs to enter full screen mode, create a per-VM section, and set `allow_fullscreen` flag there to `true`:
|
||||
|
||||
VM: {
|
||||
work: {
|
||||
allow_fullscreen = true;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
In order for the changes to take effect, restart the AppVM(s).
|
||||
|
||||
* * * * *
|
||||
|
||||
Now that you're familiar with the basics, please have a look at the rest of the [documentation](/doc/).
|
||||
@ -8,8 +8,8 @@ redirect_from:
|
||||
- /wiki/ResizeDiskImage/
|
||||
---
|
||||
|
||||
Resizing Disk Image
|
||||
-------------------
|
||||
Resize Disk Image
|
||||
-----------------
|
||||
|
||||
There are several disk images which can be easily extended.
|
||||
But pay attention to the overall consumed space of your sparse disk images.
|
||||
|
||||
@ -8,26 +8,40 @@ redirect_from:
|
||||
- /wiki/ResizeRootDiskImage/
|
||||
---
|
||||
|
||||
Resizing \`root.img\` Size
|
||||
--------------------------
|
||||
Resize Root Disk Image
|
||||
----------------------
|
||||
|
||||
The safest way to increase the size of \`root.img\` is to do it for a standalone
|
||||
VM (qvm-create --standalone) - which has its own root filesystem
|
||||
(copy of template, instead of smart sharing).
|
||||
But it should also work for a normal template (as long as changes in the
|
||||
template between reboots didn't exceed 10G).
|
||||
The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.
|
||||
|
||||
### Resize a StandaloneVM Root Image
|
||||
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
|
||||
Replace the size and the path (name) of the template as wished and run your
|
||||
modified command:
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
|
||||
truncate -s 20G /var/lib/qubes/appvms/standalonevm/root.img
|
||||
~~~
|
||||
|
||||
Then start your template or standalone VM and run:
|
||||
Then start Terminal for this StandaloneVM and run:
|
||||
|
||||
~~~
|
||||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
after that shutdown the template.
|
||||
Shutdown the StandaloneVM and you will have extended the size of it's `root.img`
|
||||
|
||||
Then you should have extended \`root.img\` in your VM/template
|
||||
|
||||
### 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.*
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
|
||||
~~~
|
||||
|
||||
Then start Terminal for this TemplateVM and run the following:
|
||||
|
||||
~~~
|
||||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the TemplateVM and you will have extended the size of it's `root.img`
|
||||
|
||||
@ -1,35 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Qubes Research
|
||||
permalink: /doc/qubes-research/
|
||||
redirect_from:
|
||||
- /en/doc/qubes-research/
|
||||
- /doc/QubesResearch/
|
||||
- /wiki/QubesResearch/
|
||||
---
|
||||
|
||||
Here are some links to various papers/research projects that somehow relate to Qubes.
|
||||
|
||||
### Attacks on Intel TXT
|
||||
|
||||
- [Attacking Intel® Trusted Execution Technology](http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf) by Rafal Wojtczuk, Joanna Rutkowska
|
||||
- [ACPI: Design Principles and Concerns](http://www.ssi.gouv.fr/IMG/pdf/article_acpi.pdf) by Loic Duflot, Olivier Levillain, and Benjamin Morin
|
||||
- [Another Way to Circumvent Intel® Trusted Execution Technology](http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf) by Rafal Wojtczuk, Joanna Rutkowska, Alex Tereshkin
|
||||
- [Attacking Intel TXT® via SINIT code execution hijacking](http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf) by Rafal Wojtczuk and Joanna Rutkowska
|
||||
|
||||
### Software attacks coming through devices
|
||||
|
||||
- [Can you still trust your network card?](http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf) by Loïc Duflot, Yves-Alexis Perez and others
|
||||
- [Remotely Attacking Network Cards (or why we do need VT-d and TXT)](http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html) by Joanna Rutkowska
|
||||
- [On Formally Verified Microkernels (and on attacking them)](http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html) by Joanna Rutkowska
|
||||
- [Following the White Rabbit: Software Attacks against Intel® VT-d](http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf) by Rafal Wojtczuk and Joanna Rutkowska
|
||||
|
||||
### Application-level security
|
||||
|
||||
- [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-70.pdf) by Matt Piotrowski
|
||||
|
||||
### VMM/Xen disagregation
|
||||
|
||||
- [[http://tjd.phlegethon.org/words/sosp11-xoar.pdf](http://tjd.phlegethon.org/words/sosp11-xoar.pdf) "Breaking Up is Hard to Do: Security and Functionality in a Commodity Hypervisor] by Patrick Colp at el.
|
||||
(Also see [this thread on xen-devel](http://www.gossamer-threads.com/lists/xen/devel/230011))
|
||||
|
||||
17
doc.md
17
doc.md
@ -1,6 +1,6 @@
|
||||
---
|
||||
layout: default
|
||||
title: Qubes OS Documentation
|
||||
title: Documentation
|
||||
permalink: /doc/
|
||||
redirect_from:
|
||||
- /en/doc/
|
||||
@ -10,13 +10,10 @@ redirect_from:
|
||||
- /wiki/QubesDocs/
|
||||
---
|
||||
|
||||
Qubes OS Documentation
|
||||
======================
|
||||
|
||||
The Basics
|
||||
----------
|
||||
* [A Simple Introduction to Qubes](/intro/)
|
||||
* [Getting Started](/doc/getting-started/)
|
||||
* [Users' FAQ](/doc/user-faq/)
|
||||
* [Mailing Lists](/doc/mailing-lists/)
|
||||
* [Further reading: How is Qubes different from...?](http://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html)
|
||||
@ -87,6 +84,17 @@ Security Guides
|
||||
* [Note regarding password-less root access in VM](/doc/vm-sudo/)
|
||||
|
||||
|
||||
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 a Transparent Tor ProxyVM (TorVM)](/doc/privacy/torvm/)
|
||||
* [How to set up a ProxyVM as a VPN Gateway](/doc/privacy/vpn/)
|
||||
|
||||
|
||||
Configuration Guides
|
||||
--------------------
|
||||
* [Configuration Files](/doc/config-files/)
|
||||
@ -155,5 +163,4 @@ For Developers
|
||||
* [Coding Guidelines](/doc/coding-style/)
|
||||
* [Documentation Guidelines](/doc/doc-guidelines/)
|
||||
* [Books for Developers](/doc/devel-books/)
|
||||
* [Research Papers](/doc/qubes-research/)
|
||||
* [Qubes OS License](/doc/license/)
|
||||
|
||||
@ -53,9 +53,9 @@ By installing these templates, you are trusting not only ITL and the
|
||||
distribution maintainers, but also the template maintainer. In addition,
|
||||
these templates may be somewhat less stable, since ITL does not test them.
|
||||
|
||||
* [Whonix](/doc/templates/whonix/)
|
||||
* [Ubuntu](/doc/templates/ubuntu/)
|
||||
* [Archlinux](/doc/templates/archlinux/)
|
||||
* [Whonix](/doc/templates/whonix/)
|
||||
* [Ubuntu](/doc/templates/ubuntu/)
|
||||
* [Archlinux](/doc/templates/archlinux/)
|
||||
|
||||
|
||||
Important Notes
|
||||
@ -75,4 +75,3 @@ 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.
|
||||
|
||||
|
||||
@ -18,4 +18,6 @@ run it on top of Qubes OS!
|
||||
|
||||
Whonix template(s) are another Qubes community contribution. Currently Whonix actively maintains those templates.
|
||||
|
||||
More details, including installation instructions on [Whonix Qubes web page](https://www.whonix.org/wiki/Qubes).
|
||||
### Installation & Details
|
||||
|
||||
To learn more and for installation instructions, read our privacy guide: [Whonix for privacy & anonymization](/en/doc/privacy/whonix/)
|
||||
|
||||
90
privacy/customizing-whonix.md
Normal file
90
privacy/customizing-whonix.md
Normal file
@ -0,0 +1,90 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Customizing Whonix
|
||||
permalink: /doc/privacy/customizing-whonix/
|
||||
---
|
||||
|
||||
Customizing Whonix
|
||||
==================
|
||||
|
||||
There are numerous ways to customize your Whonix install. All require a degree of technical knowledge and comfort with the command line.
|
||||
|
||||
### Enabling AppArmor
|
||||
|
||||
This is an optional security enhancement (for testers-only). If you're technical & interested, proceed, but do so *at your own risk!*
|
||||
|
||||
Note, if you want to use [Tor bridges](https://www.whonix.org/wiki/Bridges), AppArmor has been known in the past to cause problems with `obfsproxy` [see this issue](https://github.com/Whonix/Whonix/issues/67)
|
||||
|
||||
You will want to complete the following instructions in both the **Whonix Gateway** referred to in Qubes VM Manager as `whonix-gw` and the **Whonix Workstation** or `whonix-ws`. You only need to apply these settings to the TemplateVMs before creating any template based VMs from these Whonix templates.
|
||||
|
||||
[Since Qubes Q3, TemplateBasedVMs inherit the kernelopts setting of their TemplateVM](https://github.com/QubesOS/qubes-issues/issues/1091)
|
||||
|
||||
### Configuring Whonix Gateway
|
||||
|
||||
Launch the `dom0` terminal app `Konsole` from your Qubes App Launcher. Then get a list of current kernel parameters.
|
||||
|
||||
~~~
|
||||
qvm-prefs -l whonix-gw kernelopts
|
||||
~~~
|
||||
|
||||
As of Qubes Q3 RC1, this will show: `nopat`
|
||||
|
||||
Keep those existing kernel parameters and add `apparmor=1 security=apparmor` by entering:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s whonix-gw kernelopts "nopat apparmor=1 security=apparmor"
|
||||
~~~
|
||||
|
||||
When running the command to get a list of current kernel parameters again (just hit the arrow up key twice, so you don't have to type the command again).
|
||||
|
||||
~~~
|
||||
qvm-prefs -l whonix-gw kernelopts
|
||||
~~~
|
||||
|
||||
It should show the old and the new kernel parameters. For example:
|
||||
|
||||
~~~
|
||||
nopat apparmor=1 security=apparmor
|
||||
~~~
|
||||
|
||||
Once you started the VM, you can check if AppArmor is now active.
|
||||
|
||||
```
|
||||
sudo aa-status --enabled ; echo $?
|
||||
```
|
||||
|
||||
It should show: `0`
|
||||
|
||||
### Configuring Whonix Workstation
|
||||
|
||||
In `dom0` terminal Konsole, get a list of current kernel parameters.
|
||||
|
||||
~~~
|
||||
qvm-prefs -l whonix-ws kernelopts
|
||||
~~~
|
||||
|
||||
In current version of Qubes, this will show `nopat` as a response. To keep those existing kernel parameters and add `apparmor=1 security=apparmor` do the following:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s whonix-ws kernelopts "nopat apparmor=1 security=apparmor"
|
||||
~~~
|
||||
|
||||
When running the command to get a list of current kernel parameters again (just hit the arrow up key twice, so you don't have to type the command again).
|
||||
|
||||
~~~
|
||||
qvm-prefs -l whonix-ws kernelopts
|
||||
~~~
|
||||
|
||||
It should show the old and the new kernel parameters. For example:<br />
|
||||
|
||||
~~~
|
||||
nopat apparmor=1 security=apparmor
|
||||
~~~
|
||||
|
||||
Once you started the VM, you can check if AppArmor is now active by typing:
|
||||
|
||||
~~~
|
||||
sudo aa-status --enabled ; echo $?
|
||||
~~~
|
||||
|
||||
It should show: `0`
|
||||
58
privacy/install-whonix.md
Normal file
58
privacy/install-whonix.md
Normal file
@ -0,0 +1,58 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Install Whonix in Qubes
|
||||
permalink: /doc/privacy/install-whonix/
|
||||
---
|
||||
|
||||
|
||||
Install Whonix in Qubes
|
||||
=======================
|
||||
|
||||
Installing Whonix in Qubes is simple and only requires a few simple steps.
|
||||
|
||||
### First Time Users
|
||||
|
||||
Using privacy and anonymization tools like Whonix is not a magical solution that instantly makes you anonymous online. Please consider:
|
||||
|
||||
* Do you know what a metadata or a man-in-the-middle attack is?
|
||||
* Do you think nobody can eavesdrop on your communications because you are using Tor?
|
||||
* Do you know how Whonix works?
|
||||
|
||||
If you answered no, have a look at the [about](https://www.whonix.org/wiki/About), [warning](https://www.whonix.org/wiki/Warning) and [do not](https://www.whonix.org/wiki/DoNot) pages (on the Whonix website) to make sure Whonix is the right tool for you and you understand it's limitations.
|
||||
|
||||
---
|
||||
|
||||
### Install Templates
|
||||
|
||||
Launch the `dom0` terminal `Konsole` from your Qubes App Launcher. Then enter the following command to install the Whonix Gateway and Workstation TemplateVMs.
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-gw qubes-template-whonix-ws
|
||||
~~~
|
||||
|
||||
After doing this, you should see two new TemplateVMs in the VM Manager called `whonix-gw` and `whonix-ws`
|
||||
|
||||
### Configuring Whonix VMs
|
||||
|
||||
Create a **Whonix Gateway** ProxyVM by clicking on `Create a New VM` and select `whonix-gw` as the template and select ProxyVM as the type.
|
||||
|
||||
|
||||
|
||||
Create a **Whonix Workstation** AppVM by clicking on `Create a New VM` and select `whonix-ws` as the template and select AppVM (should be default) as the type.
|
||||
|
||||
|
||||
|
||||
Configure the **Whonix Gateway TemplateVM** to use the `sys-whonix` ProxyVM that you just created.
|
||||
|
||||
|
||||
|
||||
Great. You should be all done installing Whonix into Qubes. Use these two TemplateVMs and the ProxyVM you just added, like you would for any other VMs.
|
||||
|
||||
### Running Applications
|
||||
|
||||
To start an application in the **Whonix Workstation AppVM** that you created, launch it like any other- open the `Qubes App Launcher` and then select an app such as `Privacy Browser` which will then launch the Tor Browser
|
||||
|
||||
|
||||
### Advanced Information
|
||||
|
||||
You can learn more about [customizing Whonix here](/en/doc/privacy/customizing-whonix/)
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: doc
|
||||
title: TorVM
|
||||
permalink: /doc/torvm/
|
||||
permalink: /doc/privacy/torvm/
|
||||
redirect_from:
|
||||
- /en/doc/torvm/
|
||||
- /doc/TorVM/
|
||||
@ -63,7 +63,7 @@ Installation
|
||||
qvm-service torvm -d qubes-netwatcher
|
||||
qvm-service torvm -d qubes-firewall
|
||||
qvm-service torvm -e qubes-tor
|
||||
|
||||
|
||||
# if you created a new template in the previous step
|
||||
qvm-prefs torvm -s template fedora-21-tor
|
||||
|
||||
@ -127,7 +127,7 @@ This is accomplished through transparent TCP and transparent DNS proxying by
|
||||
the TorVM.
|
||||
|
||||
The TorVM cannot anonymize information stored or transmitted from your AppVMs
|
||||
behind the TorVM.
|
||||
behind the TorVM.
|
||||
|
||||
*Non-comprehensive* list of identifiers TorVM does not protect:
|
||||
|
||||
66
privacy/uninstall-whonix.md
Normal file
66
privacy/uninstall-whonix.md
Normal file
@ -0,0 +1,66 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Uninstall Whonix from Qubes
|
||||
permalink: /doc/privacy/uninstall-whonix/
|
||||
---
|
||||
|
||||
Uninstall Whonix from Qubes
|
||||
===========================
|
||||
|
||||
If you just want to remove your **Whonix Gateway ProxyVMs** or **Whonix Workstation AppVMs** this would not be the guide for doing that. Just use the Qubes VM Manager or command line tools for doing that.
|
||||
|
||||
*Warning: This guide will completely uninstall your underlying Whonix TemplateVMs. Only do this if you want to stop using Whonix or start over with a clean install of Whonix.*
|
||||
|
||||
### Unset or Remove Whonix TemplateVM from All VMs
|
||||
|
||||
In order to uninstall a Whonix TemplateVM, you first must ensure that no VMs have this TemplateVM set as its underlying template, or else the uninstall will not work. You can accomplish this by either unsetting the TemplateVM from VMs or simply by removing the VMs altogether. You only have to do this for VMs that use the TemplateVM that you will uninstall.
|
||||
|
||||
**Option 1a. Unsetting TemplateVM from VMs**
|
||||
|
||||
This option allows you to keep any VMs and their user storage contents. Note that the root storage will still be lost when uninstalling the TemplateVM, so you may want to backup anything important first.
|
||||
|
||||
```
|
||||
dom0 -> Qubes VM Manager -> right click Whonix VM -> Shutdown VM
|
||||
```
|
||||
|
||||
In Dom0 » Qubes VM Manager:
|
||||
|
||||
```
|
||||
dom0 -> Qubes VM Manager -> right click Whonix VM -> VM Settings -> Basic tab -> Template -> Choose a different TemplateVM from the Template list, such as your Fedora TemplateVM.
|
||||
```
|
||||
|
||||
**Option 1b. Removing VMs with TemplateVM**
|
||||
|
||||
This option will delete your user storage contents, so you may want to backup anything important first.
|
||||
|
||||
```
|
||||
dom0 -> Qubes VM Manager -> right click Whonix VM -> Remove AppVM
|
||||
```
|
||||
|
||||
### Uninstall Whonix TemplateVM
|
||||
|
||||
Note that if you have customized your TemplateVM, these will be lost when uninstalling the TemplateVM, so you may want to backup anything important first.
|
||||
|
||||
**Option 2a. Uninstall Whonix-Gateway TemplateVM**
|
||||
|
||||
Open the `dom0` terminal `Konsole`
|
||||
|
||||
```
|
||||
Qubes App Launcher (blue/grey "Q") -> System Tools -> Konsole
|
||||
```
|
||||
|
||||
Uninstall the qubes-template-whonix-gw template package.
|
||||
|
||||
~~~
|
||||
sudo yum erase qubes-template-whonix-gw
|
||||
~~~
|
||||
|
||||
**Option 2b. Uninstall Whonix-Workstation TemplateVM**
|
||||
|
||||
Open the `dom0` terminal `Konsole`
|
||||
|
||||
Uninstall the qubes-template-whonix-ws template package.
|
||||
|
||||
~~~
|
||||
sudo yum erase qubes-template-whonix-ws
|
||||
~~~
|
||||
91
privacy/updating-whonix.md
Normal file
91
privacy/updating-whonix.md
Normal file
@ -0,0 +1,91 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Updating Whonix in Qubes
|
||||
permalink: /doc/privacy/updating-whonix/
|
||||
---
|
||||
|
||||
Updating Whonix in Qubes
|
||||
========================
|
||||
|
||||
It is important to keep your Whonix templates current as to get important security updates.
|
||||
|
||||
### Configure Whonix TemplateVM proxy settings
|
||||
|
||||
|
||||
|
||||
|
||||
### Open the Whonix Terminals
|
||||
|
||||
Launch `Terminal` for both `whonix-gw` and `whonix-ws` TemplateVMs and then perform the following steps to both TemplateVMs
|
||||
|
||||
~~~
|
||||
sudo apt-get update && sudo apt-get dist-upgrade
|
||||
~~~
|
||||
|
||||
The output should look similar to this.
|
||||
|
||||
~~~
|
||||
Hit http://security.debian.org jessie/updates Release.gpg
|
||||
|
||||
Hit http://security.debian.org jessie/updates Release
|
||||
|
||||
Hit http://deb.torproject.org jessie Release.gpg
|
||||
|
||||
Hit http://ftp.us.debian.org jessie Release.gpg
|
||||
|
||||
Hit http://security.debian.org jessie/updates/main i386 Packages
|
||||
Hit http://deb.torproject.org jessie Release
|
||||
Hit http://security.debian.org jessie/updates/contrib i386 Packages
|
||||
Hit http://ftp.us.debian.org jessie Release
|
||||
Hit http://security.debian.org jessie/updates/non-free i386 Packages
|
||||
Hit http://deb.torproject.org jessie/main i386 Packages
|
||||
Hit http://security.debian.org jessie/updates/contrib Translation-en
|
||||
Hit http://ftp.us.debian.org jessie/main i386 Packages
|
||||
Hit http://security.debian.org jessie/updates/main Translation-en
|
||||
|
||||
Hit http://ftp.us.debian.org jessie/contrib i386 Packages
|
||||
|
||||
Hit http://security.debian.org jessie/updates/non-free Translation-en
|
||||
|
||||
Hit http://ftp.us.debian.org jessie/non-free i386 Packages
|
||||
|
||||
Ign http://ftp.us.debian.org jessie/contrib Translation-en
|
||||
|
||||
Ign http://ftp.us.debian.org jessie/main Translation-en
|
||||
|
||||
Ign http://ftp.us.debian.org jessie/non-free Translation-en
|
||||
|
||||
Ign http://deb.torproject.org jessie/main Translation-en_US
|
||||
|
||||
Ign http://deb.torproject.org jessie/main Translation-en
|
||||
|
||||
Reading package lists... Done
|
||||
~~~
|
||||
|
||||
However, if what you see is different or you see the word `WARNING:` you should look at our troubleshooting documentation for [Debian and Whonix](/en/doc/troubleshooting/debian-and-whonix/).
|
||||
|
||||
### Restart Services after Upgrading
|
||||
|
||||
After upgrading either (easy) reboot.
|
||||
|
||||
~~~
|
||||
sudo reboot
|
||||
~~~
|
||||
|
||||
|
||||
### Restart after Kernel Upgrades
|
||||
|
||||
When `linux-image-...` was upgraded, reboot is required to profit from security updates.
|
||||
|
||||
|
||||
Operating System Updates
|
||||
|
||||
Shutdown Whonix TemplateVM
|
||||
|
||||
~~~
|
||||
Qubes VM Manager -> right clock on TemplateVM -> Shutdown VM
|
||||
~~~
|
||||
|
||||
### Restart / Update Whonix VMs
|
||||
|
||||
If new updates were available and installed, you will need to either simply restart your running Whonix-Gateway ProxyVMs and running Whonix-Workstation AppVMs for them to be updated -- or alternatively apply this same update process again to your running VMs if not wanting to restart them right away.
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: doc
|
||||
title: VPN
|
||||
permalink: /doc/vpn/
|
||||
permalink: /doc/privacy/vpn/
|
||||
redirect_from:
|
||||
- /en/doc/vpn/
|
||||
- /doc/VPN/
|
||||
39
privacy/whonix.md
Normal file
39
privacy/whonix.md
Normal file
@ -0,0 +1,39 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Whonix for privacy & anonymizations
|
||||
permalink: /doc/privacy/whonix/
|
||||
---
|
||||
|
||||
Whonix for Privacy & Anonymity
|
||||
==============================
|
||||
|
||||
To improve your privacy & anonymity on the internet, you can install the [Whonix Template](/en/doc/templates/whonix/) on your Qubes machine.
|
||||
|
||||
[Whonix](https://www.whonix.org) is based on [Debian](https://www.debian.org) and [Tor](https://www.torproject.org) and utilizes two VMs, a **"gateway"** and a **"workstation"**. Qubes security architecture makes use of Whonix's isolation by using the gateway as a ProxyVM to route all network traffic through Tor, while the workstation is used for making AppVMs.
|
||||
|
||||
### Getting Started with Whonix
|
||||
|
||||
To install Whonix, you must have a working Qubes machine already.
|
||||
|
||||
* [Install Whonix in Qubes](/en/doc/privacy/install-whonix/)
|
||||
* [Updating Whonix in Qubes](/en/doc/privacy/updating-whonix/)
|
||||
|
||||
### Customizing & Uninstalling Whonix
|
||||
|
||||
* [Customizing Whonix](/en/doc/privacy/customizing-whonix/)
|
||||
* [Uninstall Whonix from Qubes](/en/doc/privacy/uninstall-whonix/)
|
||||
|
||||
*The following links are on Whonix's website and are technical.*
|
||||
|
||||
* [Security Advice for after installing Whonix on Qubes](https://www.whonix.org/wiki/Post_Install_Advice)
|
||||
* [How to set up Tor Bridges in Whonix on Qubes](https://www.whonix.org/wiki/Bridges#How_to_use_bridges_in_Whonix)
|
||||
* [Using Multiple Whonix-Workstations with Whonix on Qubes](https://www.whonix.org/wiki/Multiple_Whonix-Workstations#Qubes-Whonix)
|
||||
|
||||
### Support for Whonix
|
||||
|
||||
*The following links are on Whonix's site.*
|
||||
|
||||
* [Whonix Support](https://www.whonix.org/wiki/Support) - General Whonix, Debian, Tor, etc... related issues
|
||||
* [Whonix Qubes Forum](https://www.whonix.org/forum/Qubes) - Whonix specific issues
|
||||
|
||||
You can also use [Qubes support](/en/help/), but not all Qubes users run Whonix.
|
||||
138
troubleshooting/updating-debian-and-whonix.md
Normal file
138
troubleshooting/updating-debian-and-whonix.md
Normal file
@ -0,0 +1,138 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Updating Debian and Whonix
|
||||
permalink: /doc/troubleshooting/updating-debian-and-whonix/
|
||||
---
|
||||
|
||||
Updating Debian and Whonix
|
||||
==========================
|
||||
|
||||
Despite Qubes shipping with [Debian Templates](/en/doc/templates/debian/), most of Qubes core components run on Fedora and thus our documentation has better coverage for Fedora. However, Qubes has been working closely with the [Whonix](https://whonix.org) project which is based on Debian.
|
||||
|
||||
This troubleshooting guide is collection of tips about updating Whonix that also pertain to updating the normal Debian package manager. If you plan to use Debian heavily, **we highly recommend you install the Whonix templates and use them to update your normal Debian TemplateVM.**
|
||||
|
||||
*Note: some of the links on this page go to documentation on Whonix's website*
|
||||
|
||||
### Updating Error Messages
|
||||
|
||||
After running the commands to update Debian or Whonix, hopefully everything will complete perfectly.
|
||||
|
||||
~~~
|
||||
sudo apt-get update && sudo apt-get dist-upgrade
|
||||
~~~
|
||||
|
||||
However, if you see something like the following, then something went wrong.
|
||||
|
||||
~~~
|
||||
W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/contrib/binary-i386/Packages 404 Not Found
|
||||
|
||||
W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/non-free/binary-i386/Packages 404 Not Found
|
||||
|
||||
E: Some index files failed to download. They have been ignored, or old ones used instead.
|
||||
|
||||
Err http://ftp.us.debian.org jessie Release.gpg
|
||||
Could not resolve 'ftp.us.debian.org'
|
||||
Err http://deb.torproject.org jessie Release.gpg
|
||||
Could not resolve 'deb.torproject.org'
|
||||
Err http://security.debian.org jessie/updates Release.gpg
|
||||
Could not resolve 'security.debian.org'
|
||||
Reading package lists... Done
|
||||
W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg Could not resolve 'security.debian.org'
|
||||
|
||||
W: Failed to fetch http://ftp.us.debian.org/debian/dists/jessie/Release.gpg Could not resolve 'ftp.us.debian.org'
|
||||
|
||||
W: Failed to fetch http://deb.torproject.org/torproject.org/dists/jessie/Release.gpg Could not resolve 'deb.torproject.org'
|
||||
|
||||
W: Some index files failed to download. They have been ignored, or old ones used instead.
|
||||
~~~
|
||||
|
||||
This could be a temporary Tor exit relay or server failure that should fix itself. Here are some simple things to try:
|
||||
|
||||
- Check if your network connection is functional
|
||||
- Try to [change your Tor circuit](https://www.whonix.org/wiki/Arm), then try again
|
||||
- Running [whonixcheck](https://www.whonix.org/wiki/Whonixcheck) might also help diagnose the problem
|
||||
|
||||
Sometimes if you see a message such as:
|
||||
|
||||
~~~
|
||||
Could not resolve 'security.debian.org'
|
||||
~~~
|
||||
|
||||
It helps to running the following command:
|
||||
|
||||
~~~
|
||||
nslookup security.debian.org
|
||||
~~~
|
||||
|
||||
And then trying running the `update` and `upgrade` commands again.
|
||||
|
||||
~~~
|
||||
sudo apt-get update && sudo apt-get dist-upgrade
|
||||
~~~
|
||||
|
||||
*Please note: if you [disabled the Whonix APT Repository](https://www.whonix.org/wiki/Whonix-APT-Repository#Disable_Whonix_APT_Repository) you'll have to manually check for new Whonix releases and [manually install them from source code](https://www.whonix.org/wiki/Dev/Build_Documentation).*
|
||||
|
||||
### Never Install Unsigned Packages
|
||||
|
||||
If you see something like this:
|
||||
|
||||
~~~
|
||||
WARNING: The following packages cannot be authenticated!
|
||||
icedove
|
||||
Install these packages without verification [y/N]?
|
||||
~~~
|
||||
|
||||
Don't proceed! Press `N` and `<enter>`. Running `apt-get update` again should fix it. If not, something is broken or it's a [Man in the middle attack](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks), which isn't that unlikely, since we are updating over Tor exit relays and some of them are malicious. Try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm).
|
||||
|
||||
|
||||
### Signature Verification Warnings
|
||||
|
||||
There should be none at the moment. If there was such a warning, it would look like this:
|
||||
|
||||
~~~
|
||||
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681
|
||||
~~~
|
||||
|
||||
Even though, `apt-get` will automatically ignore repositories with expired keys or signatures, you will not receive upgrades from that repository. Unless the issue is already known/documented, it should be reported so it can be further investigated.
|
||||
|
||||
There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm)
|
||||
|
||||
In past various apt repositories were signed with expired key. If you want to see how the documentation looked at that point, please click on expand on the right.
|
||||
|
||||
[The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994). You saw the following warning.
|
||||
|
||||
~~~
|
||||
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681
|
||||
|
||||
W: Failed to fetch http://deb.torproject.org/torproject.org/dists/stable/Release
|
||||
W: Some index files failed to download. They have been ignored, or old ones used instead.
|
||||
~~~
|
||||
|
||||
It had already been [reported](https://trac.torproject.org/projects/tor/ticket/12994). There was no immediate danger. You could have just ignored it. Just make sure, you never install unsigned packages as explained above.
|
||||
|
||||
If you were to see other signature verification errors, those should be reported, but it shouldn't happen at this time.
|
||||
|
||||
### Changed Configuration Files
|
||||
|
||||
If you see something like the following.
|
||||
|
||||
~~~
|
||||
Setting up ifupdown ...
|
||||
Configuration file /etc/network/interfaces
|
||||
==> Modified (by you or by a script) since installation.
|
||||
==> Package distributor has shipped an updated version.
|
||||
What would you like to do about it ? Your options are:
|
||||
Y or I : install the package maintainer's version
|
||||
N or O : keep your currently-installed version
|
||||
D : show the differences between the versions
|
||||
Z : background this process to examine the situation
|
||||
The default action is to keep your current version.
|
||||
*** interfaces (Y/I/N/O/D/Z) [default=N] ? N
|
||||
~~~
|
||||
|
||||
Be careful. If the updated file isn't coming from Whonix specific package (some are called `whonix-...`), then press `n`. Otherwise anonymity/privacy/security settings deployed with Whonix might get lost. If you are an advanced user and know better, you can of course manually check the difference and merge them.
|
||||
|
||||
How could you find out if the file is coming from a Whonix specific package or not?
|
||||
|
||||
* Whonix specific packages are sometimes called `whonix-...`. In the example above it's saying `Setting up ifupdown ...`, so the file isn't coming from a Whonix specific package. In this case, you should press `n` as advised in the paragraph above.
|
||||
* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would loose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).
|
||||
Loading…
Reference in New Issue
Block a user