mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Merge pull request #1 from QubesOS/master
Bringing qubes-doc up to date with upstream.
This commit is contained in:
resurrexit
GitHub
commit
df82ffaaa7
@ -56,6 +56,21 @@ permalink: /experts/
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row featured-quotes">
|
||||
<div class="col-lg-3 col-md-3 text-center">
|
||||
<a class="avatar-large" href="https://twitter.com/petertoddbtc/status/924981145871060996" target="_blank">
|
||||
<img src="/attachment/site/expert-peter-todd.jpg">
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-lg-9 col-md-9 more-top">
|
||||
<a href="https://twitter.com/petertoddbtc/status/924981145871060996" target="_blank">
|
||||
<blockquote>"Donated a % of my consulting company's last year revenue to Qubes OS. I rely on it for all my work, and recommend it to clients too."
|
||||
<i class="fa fa-twitter fa-fw" aria-hidden="true"></i>
|
||||
<footer>Peter Todd<cite title="Source Title">, Applied Cryptography Consultant</cite></footer>
|
||||
</blockquote>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row featured-quotes">
|
||||
<div class="col-lg-3 col-md-3 text-center">
|
||||
<a class="avatar-large" href="https://twitter.com/isislovecruft" target="_blank">
|
||||
@ -86,21 +101,6 @@ permalink: /experts/
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row featured-quotes">
|
||||
<div class="col-lg-3 col-md-3 text-center">
|
||||
<a class="avatar-large" href="https://twitter.com/petertoddbtc/status/709098684672135168" target="_blank">
|
||||
<img src="/attachment/site/expert-peter-todd.jpg">
|
||||
</a>
|
||||
</div>
|
||||
<div class="col-lg-9 col-md-9 more-top">
|
||||
<a href="https://twitter.com/petertoddbtc/status/709098684672135168" target="_blank">
|
||||
<blockquote>"One of the most valuable parts of installing QubesOS was forcing myself to think through exactly what vulns [vulnerabilities] I have."
|
||||
<i class="fa fa-twitter fa-fw" aria-hidden="true"></i>
|
||||
<footer>Peter Todd<cite title="Source Title">, Applied Cryptography Consultant</cite></footer>
|
||||
</blockquote>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="row featured-quotes">
|
||||
<div class="col-lg-3 col-md-3 text-center">
|
||||
<a class="avatar-large" href="https://twitter.com/legind/status/742504400854257664" target="_blank">
|
||||
|
||||
@ -1,75 +1,34 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Users' FAQ
|
||||
permalink: /doc/user-faq/
|
||||
layout: sidebar
|
||||
title: Frequently Asked Questions
|
||||
permalink: /faq/
|
||||
redirect_from:
|
||||
- /doc/user-faq/
|
||||
- /en/doc/user-faq/
|
||||
- /doc/UserFaq/
|
||||
- /wiki/UserFaq/
|
||||
- /doc/devel-faq/
|
||||
- /en/doc/devel-faq/
|
||||
- /doc/DevelFaq/
|
||||
- /wiki/DevelFaq/
|
||||
---
|
||||
|
||||
Qubes Users' FAQ
|
||||
================
|
||||
# Frequently Asked Questions
|
||||
|
||||
[General Questions](#general-questions)
|
||||
---------------------------------------
|
||||
* [Is Qubes just another Linux distribution?](#is-qubes-just-another-linux-distribution)
|
||||
* [How is Qubes different from other security solutions?](#how-is-qubes-different-from-other-security-solutions)
|
||||
* [Does Qubes use full disk encryption (FDE)?](#does-qubes-use-full-disk-encryption-fde)
|
||||
* [What is the main concept behind Qubes?](#what-is-the-main-concept-behind-qubes)
|
||||
* [What about other approaches to security?](#what-about-other-approaches-to-security)
|
||||
* [What about safe languages and formally verified microkernels?](#what-about-safe-languages-and-formally-verified-microkernels)
|
||||
* [Why does Qubes use virtualization?](#why-does-qubes-use-virtualization)
|
||||
* [What do all these terms mean?](#what-do-all-these-terms-mean)
|
||||
* [Does Qubes run every app in a separate VM?](#does-qubes-run-every-app-in-a-separate-vm)
|
||||
* [Why does Qubes use Xen instead of KVM or some other hypervisor?](#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor)
|
||||
* [What about this other/new (micro)kernel/hypervisor?](#what-about-this-othernew-microkernelhypervisor)
|
||||
* [What's so special about Qubes' GUI virtualization?](#whats-so-special-about-qubes-gui-virtualization)
|
||||
* [Can I watch YouTube videos in qubes?](#can-i-watch-youtube-videos-in-qubes)
|
||||
* [Can I run applications, like games, which require 3D support?](#can-i-run-applications-like-games-which-require-3d-support)
|
||||
* [Is Qubes a multi-user system?](#is-qubes-a-multi-user-system)
|
||||
* [Why passwordless sudo?](#why-passwordless-sudo)
|
||||
* [How should I report documentation issues?](#how-should-i-report-documentation-issues)
|
||||
* [Will Qubes seek to get certified on the GNU Free System Distribution Guidelines (GNU FSDG)?](#will-qubes-seek-to-get-certified-under-the-gnu-free-system-distribution-guidelines-gnu-fsdg)
|
||||
* [Should I trust this website?](#should-i-trust-this-website)
|
||||
* [What does it mean to "distrust the infrastructure"?](#what-does-it-mean-to-distrust-the-infrastructure)
|
||||
* [Why does this website use Cloudflare?](#why-does-this-website-use-cloudflare)
|
||||
* [Why doesn't this website have security feature X?](#why-doesnt-this-website-have-security-feature-x)
|
||||
## General & Security
|
||||
|
||||
[Installation & Hardware Compatibility](#installation--hardware-compatibility)
|
||||
------------------------------------------------------------------------------
|
||||
* [How much disk space does each qube require?](#how-much-disk-space-does-each-qube-require)
|
||||
* [How much memory is recommended for Qubes?](#how-much-memory-is-recommended-for-qubes)
|
||||
* [Can I install Qubes on a system without VT-x?](#can-i-install-qubes-on-a-system-without-vt-x)
|
||||
* [Can I install Qubes on a system without VT-d?](#can-i-install-qubes-on-a-system-without-vt-d)
|
||||
* [What is a DMA attack?](#what-is-a-dma-attack)
|
||||
* [Can I use AMD-v instead of VT-x?](#can-i-use-amd-v-instead-of-vt-x)
|
||||
* [Can I install Qubes in a virtual machine (e.g., on VMWare)?](#can-i-install-qubes-in-a-virtual-machine-eg-on-vmware)
|
||||
* [Why does my network adapter not work?](#why-does-my-network-adapter-not-work)
|
||||
* [Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?](#can-i-install-qubes-os-together-with-other-operating-system-dual-bootmulti-boot)
|
||||
### What is the main concept behind Qubes?
|
||||
|
||||
[Common Problems](#common-problems)
|
||||
-----------------------------------
|
||||
* [Which version of Qubes am I running?](#which-version-of-qubes-am-i-running)
|
||||
* [My qubes lost Internet access after a TemplateVM update. What should I do?](#my-qubes-lost-internet-access-after-a-templatevm-update-what-should-i-do)
|
||||
* [My keyboard layout settings are not behaving correctly. What should I do?](#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do)
|
||||
* [My dom0 and/or TemplateVM update stalls when attempting to update via …](#my-dom0-andor-templatevm-update-stalls-when-attempting-to-update-via-the-gui-tool-what-should-i-do)
|
||||
* [How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?](#how-do-i-run-a-windows-hvm-in-non-seamless-mode-ie-as-a-single-window)
|
||||
* [I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.](#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
|
||||
* [I assigned a PCI device to a qube, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0)
|
||||
* [How do I install Flash in a Debian qube?](#how-do-i-install-flash-in-a-debian-qube)
|
||||
* [How do I play video files?](#how-do-i-play-video-files)
|
||||
* [How do I access my external drive?](#how-do-i-access-my-external-drive)
|
||||
* [My encrypted drive doesn't appear in Debian qube?](#my-encrypted-drive-doesnt-appear-in-debian-qube)
|
||||
* [Windows Update is stuck.](#windows-update-is-stuck)
|
||||
* [Fullscreen Firefox is frozen.](#fullscreen-firefox-is-frozen)
|
||||
* [I have weird graphics glitches like the screen turning partially black.](#i-have-weird-graphics-glitches-like-the-screen-turning-partially-black)
|
||||
|
||||
-----------------
|
||||
To build security on the "Security by Compartmentalization (or Isolation)" principle.
|
||||
|
||||
### What about other approaches to security?
|
||||
|
||||
General Questions
|
||||
-----------------
|
||||
The other two popular [approaches](https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html) are “Security by Correctness” and “Security by Obscurity.”
|
||||
We don't believe either of these approaches are capable of providing reasonable security today, nor do we believe that they will be capable of doing so in the foreseeable future.
|
||||
|
||||
### How is Qubes different from other security solutions?
|
||||
|
||||
Please see [this article](https://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html) for a thorough discussion.
|
||||
|
||||
### Is Qubes just another Linux distribution?
|
||||
|
||||
@ -77,26 +36,6 @@ If you really want to call it a distribution, then it's more of a "Xen distribut
|
||||
But Qubes is much more than just Xen packaging.
|
||||
It has its own VM management infrastructure, with support for template VMs, centralized VM updating, etc. It also has a very unique GUI virtualization infrastructure.
|
||||
|
||||
### How is Qubes different from other security solutions?
|
||||
|
||||
Please see [this article](https://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html) for a thorough discussion.
|
||||
|
||||
### Does Qubes use full disk encryption (FDE)?
|
||||
|
||||
Yes, of course!
|
||||
Full disk encryption is enabled by default.
|
||||
Specifically, we use [`LUKS`](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)/[`dm-crypt`](https://en.wikipedia.org/wiki/Dm-crypt).
|
||||
You can even [manually configure your encryption parameters](/doc/encryption-config/), if you like!
|
||||
|
||||
### What is the main concept behind Qubes?
|
||||
|
||||
To build security on the “Security by Compartmentalization (or Isolation)” principle.
|
||||
|
||||
### What about other approaches to security?
|
||||
|
||||
The other two popular [approaches](https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html) are “Security by Correctness” and “Security by Obscurity.”
|
||||
We don't believe either of these approaches are capable of providing reasonable security today, nor do we believe that they will be capable of doing so in the foreseeable future.
|
||||
|
||||
### What about safe languages and formally verified microkernels?
|
||||
|
||||
In short: these are non-realistic solutions today. We discuss this in further depth in our [Architecture Specification document](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf).
|
||||
@ -105,6 +44,13 @@ In short: these are non-realistic solutions today. We discuss this in further de
|
||||
|
||||
We believe that this is currently the only practically viable approach to implementing strong isolation while simultaneously providing compatibility with existing applications and drivers.
|
||||
|
||||
### Does Qubes use full disk encryption (FDE)?
|
||||
|
||||
Yes, of course!
|
||||
Full disk encryption is enabled by default.
|
||||
Specifically, we use [`LUKS`](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)/[`dm-crypt`](https://en.wikipedia.org/wiki/Dm-crypt).
|
||||
You can even [manually configure your encryption parameters](/doc/encryption-config/), if you like!
|
||||
|
||||
### What do all these terms mean?
|
||||
|
||||
All Qubes-specific terms are defined in the [glossary](/doc/glossary/).
|
||||
@ -119,6 +65,10 @@ A typical user would likely need around five qubes. Very paranoid users, or thos
|
||||
In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface).
|
||||
We discuss this in much greater depth in our [Architecture Specification document](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf).
|
||||
|
||||
### How is Qubes affected by Xen Security Advisories (XSAs)?
|
||||
|
||||
See the [XSA Tracker](/security/xsa/).
|
||||
|
||||
### What about this other/new (micro)kernel/hypervisor?
|
||||
|
||||
Whenever starting a discussion about another (micro)kernel or hypervisor in relation to Qubes, we strongly suggest including answers to the following questions first:
|
||||
@ -149,30 +99,6 @@ We have designed the GUI virtualization subsystem with two primary goals: securi
|
||||
Our GUI infrastructure introduces only about 2,500 lines of C code (LOC) into the privileged domain (Dom0), which is very little, and thus leaves little space for bugs and potential attacks.
|
||||
At the same time, due to the smart use of Xen shared memory, our GUI implementation is very efficient, so most virtualized applications really feel as if they were executed natively.
|
||||
|
||||
### Can I watch YouTube videos in qubes?
|
||||
|
||||
Absolutely.
|
||||
|
||||
### Can I run applications, like games, which require 3D support?
|
||||
|
||||
Those won’t fly.
|
||||
We do not provide OpenGL virtualization for Qubes.
|
||||
This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure.
|
||||
However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.
|
||||
|
||||
For further discussion about the potential for GPU passthorugh on Xen/Qubes, please see the following threads:
|
||||
|
||||
- [GPU passing to HVM](https://groups.google.com/group/qubes-devel/browse_frm/thread/31f1f2da39978573?scoring=d&q=GPU&)
|
||||
- [Clarifications on GPU security](https://groups.google.com/group/qubes-devel/browse_frm/thread/31e2d8a47c8b4474?scoring=d&q=GPU&)
|
||||
|
||||
### Is Qubes a multi-user system?
|
||||
|
||||
No.
|
||||
Qubes does not pretend to be a multi-user system.
|
||||
Qubes assumes that the user who controls Dom0 controls the whole system.
|
||||
It would be very difficult to **securely** implement multi-user support.
|
||||
See [here](https://groups.google.com/group/qubes-devel/msg/899f6f3efc4d9a06) for details.
|
||||
|
||||
### Why passwordless sudo?
|
||||
|
||||
Please refer to [this page](https://www.qubes-os.org/doc/vm-sudo/).
|
||||
@ -227,11 +153,45 @@ So, if feature X isn't enabled, it's most likely for one of three reasons:
|
||||
3. Our platform supports it, but we're not aware that we can enable it or have forgotten to do so.
|
||||
(If it seems like this is the case, let us know!)
|
||||
|
||||
----------
|
||||
|
||||
Installation & Hardware Compatibility
|
||||
-------------------------------------
|
||||
## Users
|
||||
|
||||
(See also: [System Requirements](/doc/system-requirements/), [Hardware Compatibility List](/hcl/), and [Certified Laptops](/doc/certified-laptops/).)
|
||||
### Can I watch YouTube videos in qubes?
|
||||
|
||||
Absolutely.
|
||||
|
||||
### Can I run applications, like games, which require 3D support?
|
||||
|
||||
Those won’t fly.
|
||||
We do not provide OpenGL virtualization for Qubes.
|
||||
This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure.
|
||||
However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.
|
||||
|
||||
For further discussion about the potential for GPU passthrough on Xen/Qubes, please see the following threads:
|
||||
|
||||
- [GPU passing to HVM](https://groups.google.com/group/qubes-devel/browse_frm/thread/31f1f2da39978573?scoring=d&q=GPU&)
|
||||
- [Clarifications on GPU security](https://groups.google.com/group/qubes-devel/browse_frm/thread/31e2d8a47c8b4474?scoring=d&q=GPU&)
|
||||
|
||||
### Is Qubes a multi-user system?
|
||||
|
||||
No.
|
||||
Qubes does not pretend to be a multi-user system.
|
||||
Qubes assumes that the user who controls Dom0 controls the whole system.
|
||||
It would be very difficult to **securely** implement multi-user support.
|
||||
See [here](https://groups.google.com/group/qubes-devel/msg/899f6f3efc4d9a06) for details.
|
||||
|
||||
### What are the system requirements for Qubes OS?
|
||||
|
||||
See the [System Requirements](/doc/system-requirements/).
|
||||
|
||||
### Is there a list of hardware that is compatible with Qubes OS?
|
||||
|
||||
See the [Hardware Compatibility List](/hcl/).
|
||||
|
||||
### Is there any certified hardware for Qubes OS?
|
||||
|
||||
See [Certified Hardware](/doc/certified-hardware/).
|
||||
|
||||
### How much disk space does each qube require?
|
||||
|
||||
@ -273,14 +233,14 @@ But since you can read the whole memory, it isn't that hard.
|
||||
Now, how does this apply to Qubes OS?
|
||||
The above attack requires access to a PCI device, which means that it can be performed only from NetVM / UsbVM, so someone must first break into one of those VMs.
|
||||
But this isn't that hard, because there is a lot of complex code handling network traffic.
|
||||
Recent bugs includes DHCP client, DNS client, etc.
|
||||
Recent bugs include DHCP client, DNS client, etc.
|
||||
Most attacks on NetVM / UsbVM (but not all!) require being somewhat close to the target system - for example connected to the same WiFi network, or in the case of a UsbVM, having physical acccess to a USB port.
|
||||
|
||||
### Can I use AMD-v instead of VT-x?
|
||||
|
||||
See [this message](http://groups.google.com/group/qubes-devel/msg/6412170cfbcb4cc5).
|
||||
|
||||
### Can I install Qubes in a virtual machine (e.g., on VMWare)?
|
||||
### Can I install Qubes in a virtual machine (e.g., on VMware)?
|
||||
|
||||
Some users have been able to do this, but it is neither recommended nor supported. Qubes should be installed bare-metal. (After all, it uses its own bare-metal hypervisor!)
|
||||
|
||||
@ -292,12 +252,9 @@ Open a terminal and run `sudo yum install linux-firmware` in the TemplateVM upon
|
||||
|
||||
### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?
|
||||
|
||||
You shouldn't do that, because it pose a security risk for your Qubes OS installation.
|
||||
But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/).
|
||||
It starts with explanation what is wrong with using such setup.
|
||||
|
||||
Common Problems
|
||||
---------------
|
||||
You shouldn't do that, because it poses a security risk for your Qubes OS installation.
|
||||
But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/),
|
||||
it begins with an explanation of the risks with such a setup.
|
||||
|
||||
### Which version of Qubes am I running?
|
||||
|
||||
@ -307,7 +264,7 @@ See [here](/doc/version-scheme/#check-installed-version).
|
||||
|
||||
Run `systemctl enable NetworkManager-dispatcher.service` in the TemplateVM upon which your NetVM is based.
|
||||
You may have to reboot afterward for the change to take effect.
|
||||
(Note: This is an upstream problem. See [here](https://bugzilla.redhat.com/show_bug.cgi?id=974811).
|
||||
(Note: This is an upstream problem. See [here](https://bugzilla.redhat.com/show_bug.cgi?id=974811)).
|
||||
For details, see the qubes-users mailing list threads [here](https://groups.google.com/d/topic/qubes-users/xPLGsAJiDW4/discussion) and [here](https://groups.google.com/d/topic/qubes-users/uN9G8hjKrGI/discussion).)
|
||||
|
||||
### My keyboard layout settings are not behaving correctly. What should I do?
|
||||
@ -338,15 +295,13 @@ In your TemplateVMs, open a terminal and run `sudo yum upgrade`.
|
||||
|
||||
Enable "debug mode" in the qube's settings, either by checking the box labeled "Run in debug mode" in the Qubes VM Manager qube settings menu or by running the [qvm-prefs command](/doc/dom0-tools/qvm-prefs/).)
|
||||
|
||||
|
||||
### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.
|
||||
|
||||
|
||||
This is probably because one of the controllers does not support reset.
|
||||
In Qubes R2 any such errors were ignored but in Qubes R3.0 they are not.
|
||||
A device that does not support reset is not safe and generally should not be assigned to a VM.
|
||||
|
||||
Most likely the offending controller is a USB3.0 device.
|
||||
Most likely the offending controller is a USB 3.0 device.
|
||||
You can remove this controller from the usbVM, and see if this allows the VM to boot.
|
||||
Alternatively you may be able to disable USB 3.0 in the BIOS.
|
||||
|
||||
@ -385,8 +340,7 @@ or
|
||||
MODALIAS=`cat /sys/bus/pci/devices/0000:<BDF>/modalias`
|
||||
MOD=`modprobe -R $MODALIAS | head -n 1`
|
||||
echo 0000:<BDF> > /sys/bus/pci/drivers/$MOD/bind
|
||||
|
||||
|
||||
|
||||
### How do I install Flash in a Debian qube?
|
||||
|
||||
The Debian way is to install the flashplugin-nonfree package.
|
||||
@ -472,3 +426,52 @@ If it seems like the issue described in [this thread](https://github.com/QubesOS
|
||||
- Q → System Tools → Window Manager Tweaks → Compositor → uncheck "Enable display compositing"
|
||||
|
||||
Please report (via the mailing lists) if you experience this issue, and whether disabling the compositor fixes it for you or not.
|
||||
|
||||
----------
|
||||
|
||||
## Developers
|
||||
|
||||
### Why does dom0 need to be 64-bit?
|
||||
|
||||
Since 2013 [Xen has not supported 32-bit x86 architecture](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and Intel VT-d, which Qubes uses to isolate devices and drivers, is available on Intel 64-bit processors only.
|
||||
|
||||
In addition, with features like improved ASLR, it is often more difficult to exploit a bug on x64 Linux than x86 Linux.
|
||||
While we designed Qubes from the beginning to limit potential attack vectors, we still realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, however simple, might contain some bugs.
|
||||
Plus since we haven't implemented a separate storage domain, the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface.
|
||||
So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer.
|
||||
The 64-bit option provides some (little perhaps, but some) more protection against some classes of attacks, and at the same time does not have any disadvantages except the extra requirement of a 64 bit processor.
|
||||
And even though Qubes now "needs" a 64 bit processor, it didn't make sense to run Qubes on a system without 3-4GB of memory, and those have 64-bit CPUs anyway.
|
||||
|
||||
### What is the recommended build environment for Qubes OS?
|
||||
|
||||
Any rpm-based, 64-bit environment, the preferred OS being Fedora.
|
||||
|
||||
### How do I build Qubes from sources?
|
||||
|
||||
See [these instructions](/doc/qubes-builder/).
|
||||
|
||||
### How do I submit a patch?
|
||||
|
||||
See the [Qubes Source Code Repositories](/doc/source-code/) article.
|
||||
|
||||
### What is Qubes' attitude toward changing guest distros?
|
||||
|
||||
We try to respect each distro's culture, where possible.
|
||||
See the discussion on issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an example.
|
||||
|
||||
The policy is there mostly to ease maintenance, on several levels:
|
||||
|
||||
* Less modifications means easier migration to new upstream distribution
|
||||
releases.
|
||||
* The upstream documentation matches the distribution running in the Qubes VM.
|
||||
* We're less likely to introduce Qubes-specific issues.
|
||||
* Each officially supported distribution (ideally) should offer the same set of
|
||||
Qubes-specific features - a change in one supported distribution should be
|
||||
followed also in others, including new future distributions.
|
||||
|
||||
### Is I/O emulation component (QEMU) part of the Trusted Computing Base (TCB)?
|
||||
|
||||
No. Unlike many other virtualization systems, Qubes takes special effort to keep QEMU _outside_ of the TCB.
|
||||
This has been achieved thanks to the careful use of Xen's stub domain feature.
|
||||
For more details about how we improved on Xen's native stub domain use, see [here](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html).
|
||||
|
||||
@ -369,7 +369,7 @@ You must be subscribed in order to post to this list.
|
||||
[HCL]: /doc/hcl/
|
||||
[Installation Guide]: /doc/installation-guide/
|
||||
[System Requirements]: /doc/system-requirements/
|
||||
[User FAQ]: /doc/user-faq/
|
||||
[User FAQ]: /faq/#users
|
||||
[documentation]: /doc/
|
||||
[thunderbird-newsgroup]: https://support.mozilla.org/en-US/kb/creating-newsgroup-account
|
||||
[qubes-users-web]: https://groups.google.com/group/qubes-users
|
||||
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Developers' FAQ
|
||||
permalink: /doc/devel-faq/
|
||||
redirect_from:
|
||||
- /en/doc/devel-faq/
|
||||
- /doc/DevelFaq/
|
||||
- /wiki/DevelFaq/
|
||||
---
|
||||
|
||||
Qubes Developers' FAQ
|
||||
=====================
|
||||
|
||||
Why does dom0 need to be 64-bit?
|
||||
--------------------------------
|
||||
|
||||
Since 2013 [Xen has not supported 32-bit x86 architecture](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and Intel VT-d, which Qubes uses to isolate devices and drivers, is available on Intel 64-bit processors only.
|
||||
|
||||
In addition, with features like improved ASLR, it is often more difficult to exploit a bug on x64 Linux than x86 Linux.
|
||||
While we designed Qubes from the beginning to limit potential attack vectors, we still realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, however simple, might contain some bugs.
|
||||
Plus since we haven't implemented a separate storage domain, the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface.
|
||||
So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer.
|
||||
The 64-bit option provides some (little perhaps, but some) more protection against some classes of attacks, and at the same time does not have any disadvantages except the extra requirement of a 64 bit processor.
|
||||
And even though Qubes now "needs" a 64 bit processor, it didn't make sense to run Qubes on a system without 3-4GB of memory, and those have 64-bit CPUs anyway.
|
||||
|
||||
What is the recommended build environment for Qubes OS?
|
||||
------------------------------------------
|
||||
|
||||
Any rpm-based, 64-bit environment, the preferred OS being Fedora.
|
||||
|
||||
How do I build Qubes from sources?
|
||||
--------------------------------
|
||||
|
||||
See [these instructions](/doc/qubes-builder/).
|
||||
|
||||
How do I submit a patch?
|
||||
------------------------
|
||||
|
||||
See the [Qubes Source Code Repositories](/doc/source-code/) article.
|
||||
|
||||
What is Qubes' attitude toward changing guest distros?
|
||||
------------------------------------------------------
|
||||
|
||||
We try to respect each distro's culture, where possible.
|
||||
See the discussion on issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an example.
|
||||
|
||||
The policy is there mostly to ease maintenance, on several levels:
|
||||
|
||||
* Less modifications means easier migration to new upstream distribution
|
||||
releases.
|
||||
* The upstream documentation matches the distribution running in the Qubes VM.
|
||||
* We're less likely to introduce Qubes-specific issues.
|
||||
* Each officially supported distribution (ideally) should offer the same set of
|
||||
Qubes-specific features - a change in one supported distribution should be
|
||||
followed also in others, including new future distributions.
|
||||
|
||||
Is I/O emulation component (QEMU) part of the Trusted Computing Base (TCB)?
|
||||
------------------------
|
||||
|
||||
No. Unlike many other virtualization systems, Qubes takes special effort to keep QEMU _outside_ of the TCB.
|
||||
This has been achieved thanks to the careful use of Xen's stub domain feature.
|
||||
For more details about how we improved on Xen's native stub domain use, see [here](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html).
|
||||
@ -7,8 +7,6 @@ permalink: /doc/package-contributions/
|
||||
Package Contributions
|
||||
=====================
|
||||
|
||||
**Notice:** *This is an unofficial draft. Once this information is official, this notice will be removed.*
|
||||
|
||||
We're very grateful to the talented and hard-working community members who contribute software packages to Qubes OS.
|
||||
This page explains the inclusion criteria and procedures for such packages, as well as the roles and responsibilities of those involved.
|
||||
|
||||
@ -23,7 +21,7 @@ In order to be accepted, packages must:
|
||||
* Have a clearly-defined use case for Qubes users.
|
||||
* Not be unduly burdensome to review.
|
||||
|
||||
(Please note that we always reserve the right add criteria to this list.)
|
||||
(Please note that we always reserve the right to add criteria to this list.)
|
||||
|
||||
Contribution Procedure
|
||||
----------------------
|
||||
|
||||
@ -17,6 +17,7 @@ ways in which you can help:
|
||||
* Audit the [source code]
|
||||
* [Report security issues]
|
||||
* [Send patches][patch] to fix bugs or implement features
|
||||
* [Contribute packages]
|
||||
* [Report bugs]
|
||||
* [Test new releases and updates]
|
||||
* Submit [HCL reports] for your hardware
|
||||
@ -31,7 +32,6 @@ ways in which you can help:
|
||||
* Follow us on [Twitter]
|
||||
* Join us on [Reddit]
|
||||
* Like us on [Facebook]
|
||||
* Support our [StackExchange] proposal
|
||||
* And last but not least, tell your friends and colleagues about how Qubes
|
||||
can help them secure their digital lives!
|
||||
|
||||
@ -60,6 +60,7 @@ be grateful to [receive your patch][patch].
|
||||
[source code]: /doc/source-code/
|
||||
[Report security issues]: /security/
|
||||
[patch]: /doc/source-code/#how-to-send-patches
|
||||
[Contribute packages]: /doc/package-contributions
|
||||
[Report bugs]: /doc/reporting-bugs/
|
||||
[Test new releases and updates]: /doc/testing/
|
||||
[HCL reports]: /doc/hcl/
|
||||
@ -72,7 +73,6 @@ be grateful to [receive your patch][patch].
|
||||
[Twitter]: https://twitter.com/QubesOS
|
||||
[Reddit]: https://www.reddit.com/r/Qubes/
|
||||
[Facebook]: https://www.facebook.com/QubesOS
|
||||
[StackExchange]: https://area51.stackexchange.com/proposals/98519/qubes-os
|
||||
[GitHub issues]: https://github.com/QubesOS/qubes-issues/issues
|
||||
[qubes-devel]: /mailing-lists/#qubes-devel
|
||||
[Community-Developed Feature Tracker]: https://www.qubes-os.org/qubes-issues/
|
||||
|
||||
@ -228,9 +228,9 @@ technical details have been omitted here for the sake of presentation.
|
||||
[Xen]: https://www.xenproject.org
|
||||
[paper-compart]: https://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf
|
||||
[doc]: /doc/
|
||||
[user-faq]: /doc/user-faq/
|
||||
[user-faq]: /faq/#users
|
||||
[system-doc]: /doc/system-doc/
|
||||
[devel-faq]: /doc/devel-faq/
|
||||
[devel-faq]: /faq/#developers
|
||||
[downloads]: /downloads/
|
||||
[getting started]: /getting-started/
|
||||
|
||||
|
||||
@ -16,11 +16,11 @@ Background
|
||||
|
||||
A Disposable VM (DispVM) is a lightweight VM that can be created quickly and which will disappear when it is finished with. Usually a Disposable VM is created in order to host a single application, like a viewer or an editor. This means that you can safely work with files without risk of compromising any of your VMs. Changes made to a file opened in a disposable VM are passed back to the originating VM. See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why would one want to use a Disposable VM.
|
||||
|
||||
By default a Disposable VM will inherit the NetVM and firewall settings of the ancestor VM, that is the VM it is launched from. Thus if an AppVM uses sys-net as NetVM (instead of, say, sys-whonix), any DispVM launched from this AppVM will also have sys-net as its NetVM. You can change this behaviour for individual VMs: in the Qubes Manager open VM Settings for the VM in question and go to the "Advanced" tab. Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.
|
||||
By default a DispVM will inherit the NetVM and firewall settings of the ancestor VM, that is the VM it is launched from. Thus if an AppVM uses sys-net as NetVM (instead of, say, sys-whonix), any DispVM launched from this AppVM will also have sys-net as its NetVM. You can change this behaviour for individual VMs: in Qubes VM Manager open VM Settings for the VM in question and go to the "Advanced" tab. Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.
|
||||
|
||||
A Disposable VM launched from the Start Meny inherits the NetVM of a so-called internal TempVM, the *[DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).* By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Meny; only changing the DVM Template's own NetVM does.
|
||||
A DispVM launched from the Start Menu inherits the NetVM of the [DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template). By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and, as a so-called internal VM, hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.
|
||||
|
||||
Once a DispVM has been created it will appear in the Qubes Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM.
|
||||
Once a DispVM has been created it will appear in Qubes VM Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM.
|
||||
|
||||
|
||||
Opening a file in a Disposable VM (via GUI)
|
||||
|
||||
@ -24,6 +24,8 @@ Using and Managing USB Devices
|
||||
Creating and Using a USB qube
|
||||
-----------------------------
|
||||
|
||||
**Warning:** This has the potential to prevent you from connecting a keyboard to Qubes via USB. There are problems with doing this with a encrypted install (LUKS). If you find yourself in this situation, see this [issue][2270-comm23].
|
||||
|
||||
The connection of an untrusted USB device to dom0 is a security risk since dom0,
|
||||
like almost every OS, reads partition tables automatically and since the whole
|
||||
USB stack is put to work to parse the data presented by the USB device in order
|
||||
@ -110,7 +112,7 @@ opt to create a USB qube during installation. This also occurs automatically if
|
||||
you choose to [create a USB qube] using the `qubesctl` method, which is the
|
||||
first pair of steps in the linked section.)
|
||||
|
||||
**Warning** USB keyboard cannot be used to type the disk passphrase
|
||||
**Warning:** USB keyboard cannot be used to type the disk passphrase
|
||||
if USB controllers were hidden from dom0. Before hiding USB controllers
|
||||
make sure your laptop keyboard is not internally connected via USB
|
||||
(by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand
|
||||
@ -165,7 +167,7 @@ Edit the `qubes.InputKeyboard` policy file in dom0, which is located here:
|
||||
|
||||
Add a line like this one to the top of the file:
|
||||
|
||||
sys-usb dom0 ask,user=root
|
||||
sys-usb dom0 allow,user=root
|
||||
|
||||
(Change `sys-usb` to your desired USB qube.)
|
||||
|
||||
@ -183,7 +185,7 @@ Edit the `qubes.InputMouse` policy file in dom0, which is located here:
|
||||
|
||||
Add a line like this to the op of the file:
|
||||
|
||||
sys-usb dom0 ask,user=root
|
||||
sys-usb dom0 allow,user=root
|
||||
|
||||
(Change `sys-usb` to your desired USB qube.)
|
||||
|
||||
@ -378,9 +380,10 @@ This feature is not yet available in Qubes Manager however, if you would like to
|
||||
[623]: https://github.com/QubesOS/qubes-issues/issues/623
|
||||
[1072-comm1]: https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051
|
||||
[1072-comm2]: https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309
|
||||
[2270-comm23]: https://github.com/QubesOS/qubes-issues/issues/2270#issuecomment-242900312
|
||||
[1082]: https://github.com/QubesOS/qubes-issues/issues/1082
|
||||
[hide-usb]: #how-to-hide-all-usb-controllers-from-dom0
|
||||
[faq-usbvm]: /doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot
|
||||
[faq-usbvm]: /faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot
|
||||
[AEM]: /doc/anti-evil-maid/
|
||||
[1618]: https://github.com/QubesOS/qubes-issues/issues/1618
|
||||
[create a USB qube]: #creating-and-using-a-usb-qube
|
||||
|
||||
7
doc.md
7
doc.md
@ -23,13 +23,14 @@ The Basics
|
||||
* [Video Tours](/video-tours/)
|
||||
* [Screenshots](/screenshots/)
|
||||
* [Getting Started](/getting-started/)
|
||||
* [User FAQ](/doc/user-faq/)
|
||||
* [User FAQ](/faq/#users)
|
||||
* [Mailing Lists](/mailing-lists/)
|
||||
* [How to Contribute](/doc/contributing/)
|
||||
|
||||
Security Information
|
||||
--------------------
|
||||
* [Security Center](/security/)
|
||||
* [Security FAQ](/faq/#general--security)
|
||||
* [Security Pack](/security/pack/)
|
||||
* [Security Bulletins](/security/bulletins/)
|
||||
* [Canaries](/security/canaries/)
|
||||
@ -203,10 +204,11 @@ Developer Documentation
|
||||
|
||||
The Basics
|
||||
----------
|
||||
* [Developer FAQ](/doc/devel-faq/)
|
||||
* [Developer FAQ](/faq/#developers)
|
||||
* [Report a Security Issue](/security/)
|
||||
* [Report a Bug](/doc/reporting-bugs/)
|
||||
* [How to Contribute](/doc/contributing/)
|
||||
* [Package Contributions](/doc/package-contributions/)
|
||||
* [Testing new releases and updates](/doc/testing/)
|
||||
* [Source Code](/doc/source-code/)
|
||||
* [Qubes OS License](/doc/license/)
|
||||
@ -221,6 +223,7 @@ The Basics
|
||||
Security Information
|
||||
--------------------
|
||||
* [Security Center](/security/)
|
||||
* [Security FAQ](/faq/#general--security)
|
||||
* [Security Pack](/security/pack/)
|
||||
* [Security Bulletins](/security/bulletins/)
|
||||
* [Security Bulletin Checklist](/security/bulletins/checklist/)
|
||||
|
||||
@ -107,7 +107,7 @@ Maid passphrase to the new configuration. Please consult the Anti Evil Maid
|
||||
|
||||
If you use USB VM, you may encounter problem with starting it on updated Xen
|
||||
version (because of strict default settings). Take a look at
|
||||
[User FAQ](/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
|
||||
[User FAQ](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
|
||||
for details.
|
||||
|
||||
Once you have upgraded dom0, you can install new templates from Qubes R3.1
|
||||
|
||||
@ -6,7 +6,7 @@ redirect_from:
|
||||
- /doc/kali/
|
||||
---
|
||||
|
||||
**General Remainder:**
|
||||
**General reminder:**
|
||||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
@ -27,15 +27,10 @@ There are multiple ways to create a Kali Linux VM:
|
||||
2. Clone the Qubes OS Debian image and turn it into a Kali Linux distribution using [katoolin]. Explained [here](#katoolin).
|
||||
3. Clone the Qubes OS 'jessie' Debian template, upgrade it to 'stretch'
|
||||
(Debian 9.0) and turn it into a Kali linux template. Explained
|
||||
[here](#debian-upgrade).
|
||||
[here](#templatevm-from-debian).
|
||||
|
||||
## Alternative Options to Kali
|
||||
|
||||
- [BlackArch][qubes-blackarch]
|
||||
- [PenTester Framework (PTF)][qubes-ptf]
|
||||
- [Pentesting][qubes-pentesting]
|
||||
|
||||
## Kali Linux HVM <a name="hvm"/>
|
||||
Kali Linux HVM <a name="hvm"/>
|
||||
--------------
|
||||
|
||||
1. Download the Kali installation DVD
|
||||
|
||||
@ -45,11 +40,12 @@ There are multiple ways to create a Kali Linux VM:
|
||||
|
||||
qvm-start <hvm-name> --cdrom <vm-name>:/home/user/Downloads/<iso-name>.iso
|
||||
|
||||
## Create Debian Based Kali Template <a name="katoolin"/>
|
||||
Debian based Kali Template with Katoolin <a name="katoolin"/>
|
||||
----------------------------------------
|
||||
|
||||
Katoolin is a script (written in Python) which helps you to install Kali tools.
|
||||
|
||||
1. *(Optional)* Install `debian-8` template (if not already installed)
|
||||
1. (Optional) Install `debian-8` template (if not already installed)
|
||||
|
||||
2. Update your `debian-8` template
|
||||
|
||||
@ -74,7 +70,7 @@ Katoolin is a script (written in Python) which helps you to install Kali tools.
|
||||
sudo apt-get dist-upgrade
|
||||
sudo apt-get autoremove
|
||||
|
||||
6. Install Katoolin and add Kali Linux repositories
|
||||
5. Install Katoolin and add Kali Linux repositories
|
||||
|
||||
1. Install Katoolin
|
||||
|
||||
@ -127,12 +123,12 @@ Katoolin is a script (written in Python) which helps you to install Kali tools.
|
||||
|
||||
What do you want to do ?> ^CShutdown requested...Goodbye...
|
||||
|
||||
7. Clean up and update `kali` template
|
||||
6. Clean up and update `kali` template
|
||||
|
||||
sudo apt-get dist-upgrade
|
||||
sudo apt-get autoremove
|
||||
|
||||
8. Shutdown and trim `kali` template
|
||||
7. Shutdown and trim `kali` template
|
||||
|
||||
- Shutdown `kali` template
|
||||
|
||||
@ -142,9 +138,9 @@ Katoolin is a script (written in Python) which helps you to install Kali tools.
|
||||
|
||||
qvm-trim-template kali
|
||||
|
||||
9. Start image
|
||||
8. Start image
|
||||
|
||||
11. Install tools
|
||||
9. Install tools
|
||||
|
||||
1. View Categories
|
||||
|
||||
@ -160,15 +156,17 @@ Katoolin is a script (written in Python) which helps you to install Kali tools.
|
||||
|
||||
- **Note:** The `all` option does not work for `Information Gathering`, `Web Apps`, `Forensic Tools`, `Reverse Engineering` and `Extra`.
|
||||
|
||||
12. Create a AppVMs based on the `kali` template
|
||||
10. Create a AppVMs based on the `kali` template
|
||||
|
||||
- (Optional) Attach necessary devices
|
||||
|
||||
## Installing Kali from a Debian template <a name="debian-upgrade"/>
|
||||
Kali Linux TemplateVM from a Debian template <a name="debian-upgrade"/><a name="templatevm-from-debian"/>
|
||||
--------------------------------------------
|
||||
|
||||
This section will explain how to create your own [Kali] Linux VM as a VM
|
||||
template. The basic idea is to personalize the template with the tools you need
|
||||
and then spin up isolated AppVMs based on the template.
|
||||
This section will explain how to create your own [Kali] Linux TemplateVM based
|
||||
on a Debian 9.0 (Stretch) TemplateVM. The basic idea is to personalize the
|
||||
template with all the tools needed, and then spin up isolated AppVMs based on
|
||||
the template.
|
||||
|
||||
This has been tested on Qubes OS 3.2.
|
||||
|
||||
@ -176,133 +174,122 @@ The steps can be summarised as:
|
||||
|
||||
1. Install Qubes' Debian 8.0 (Jessie) template
|
||||
2. Upgrade the template to Debian 9.0 (Stretch)
|
||||
3. Install kali through the ``kali-linux-full`` package
|
||||
4. Use the template to build appVM so that you can maintain isolation between
|
||||
3. Install Kali Linux through the ``kali-linux-full`` package
|
||||
4. Use the template to build AppVM so that you can maintain isolation between
|
||||
e.g. pentesting jobs
|
||||
|
||||
### Get Kali Linux GPG key ###
|
||||
|
||||
Steps to build a Kali template
|
||||
------------------------------
|
||||
**CAUTION:** Before proceeding, please carefully read [On Digital Signatures and Key Verification][qubes-verifying-signatures].
|
||||
This website cannot guarantee that any PGP key you download from the Internet is authentic.
|
||||
Always obtain a trusted key fingerprint via other channels, and always check any key you download against your trusted copy of the fingerprint.
|
||||
|
||||
### Get the GPG key
|
||||
This step is required since by (security) default a TemplateVM do not have a
|
||||
direct Internet connectivity. Users understanding the risks of enabling such
|
||||
access can change this configuration in firewall settings for the TemplateVM.
|
||||
|
||||
1. You'll need to fetch the Kali GPG key from a dispVM as the template you'll
|
||||
build won't have direct internet connectivity unless you enable it from the
|
||||
firewall:
|
||||
1. Retrive the Kali Linux GPG key using a DispVM.
|
||||
|
||||
# in a dispVM
|
||||
gpg --keyserver hkp://keys.gnupg.net --recv-key 7D8D0BF6
|
||||
gpg --list-keys --with-fingerprint 7D8D0BF6
|
||||
gpg --export --armor 7D8D0BF6 > kali.asc
|
||||
[user@xxxx-dvm ~]$ gpg --keyserver hkp://keys.gnupg.net --recv-key 7D8D0BF6
|
||||
[user@xxxx-dvm ~]$ gpg --list-keys --with-fingerprint 7D8D0BF6
|
||||
[user@xxxx-dvm ~]$ gpg --export --armor 7D8D0BF6 > kali-key.asc
|
||||
|
||||
2. **DO NOT TURN OFF** the dispVM
|
||||
2. **DO NOT TURN OFF** the DispVM, the `kali-key.asc` file will be copied to
|
||||
the Kali Linux template in a further step.
|
||||
|
||||
3. Make sure the key ID is the valid one listed on the [Kali website]. Ideally,
|
||||
verify the fingerprint through other channels as recommended on that link.
|
||||
3. Make sure the key is the authentic Kali key.
|
||||
See the [Kali website] for further advice and instructions on verification.
|
||||
|
||||
Once you have the key, keep the dispVM on as you'll need to copy the key over
|
||||
to the Kali template.
|
||||
### Create a Kali Linux (rolling) template ###
|
||||
|
||||
### Customize the template
|
||||
These instructions will show you how to upgrade a Debian 9 TemplateVM to Kali Linux.
|
||||
|
||||
1. Install [the debian-8 template] if not already installed
|
||||
**Note:** The prompt on each line indicates where each command should be entered
|
||||
(`@dom0`, `@kali-rolling` or `@xxxx-dvm`).
|
||||
|
||||
2. Clone the debian template and start a terminal in it:
|
||||
1. Ensure the base template is not running.
|
||||
|
||||
# in dom0:
|
||||
qvm-clone debian-8 debian-9
|
||||
qvm-run -a debian-9 gnome-terminal
|
||||
[user@dom0 ~]$ qvm-shutdown debian-9
|
||||
|
||||
# in the debian-9 template terminal:
|
||||
# substitute jessie for stretch in
|
||||
sudo -s
|
||||
sensible-editor /etc/apt/sources.list
|
||||
sensible-editor /etc/apt/sources.list.d/qubes-r3.list
|
||||
apt-get update && apt-get dist-upgrade
|
||||
# (hat tip: [the Debian wiki])
|
||||
2. Clone the base template and start a terminal in the new template.
|
||||
|
||||
Restart the template when done and make sure you can open a terminal.
|
||||
[user@dom0 ~]$ qvm-clone debian-9 kali-rolling
|
||||
[user@dom0 ~]$ qvm-run -a kali-rolling gnome-terminal
|
||||
|
||||
3. Prepare the kali template:
|
||||
3. Copy the Kali GPG key from the DispVM to the new template:
|
||||
|
||||
# in dom0:
|
||||
qvm-shutdown debian-9
|
||||
qvm-clone debian-9 kali-tpl
|
||||
qvm-run -a kali-tpl gnome-terminal
|
||||
[user@xxxx-dvm ~]$ qvm-copy-to-vm kali-rolling kali-key.asc
|
||||
|
||||
The DispVM can now be turned off.
|
||||
|
||||
3. Add the sources to install Kali linux to the `kali-tpl` template:
|
||||
4. Add the Kali GPG key to the list of keys trusted to authenticate packages:
|
||||
|
||||
# in kali-tpl:
|
||||
sudo -s
|
||||
echo 'deb http://http.kali.org/kali kali-rolling main non-free contrib' >> /etc/apt/sources.list
|
||||
[user@kali-rolling ~]$ /home/user/QubesIncoming/dispXXX/kali-key.asc | sudo apt-key add -
|
||||
|
||||
4. Copy the Kali key from the dispVM into the template:
|
||||
This command should return `OK` on a line by itself.
|
||||
|
||||
# in the dispVM:
|
||||
qvm-copy-to-vm kali-tpl kali.asc
|
||||
5. Attempt the upgrade process in the new template.
|
||||
|
||||
# in kali-tpl:
|
||||
cat /home/user/QubesIncoming/dispXXX/kali.asc | sudo apt-key add -
|
||||
[user@kali-rolling ~]$ sudo cat <<EOF > /etc/apt/sources.list.d/kali.list
|
||||
# Kali Linux repository
|
||||
deb http://http.kali.org/kali kali-rolling main non-free contrib
|
||||
EOF
|
||||
[user@kali-rolling ~]$ sudo apt-get update
|
||||
[user@kali-rolling ~]$ sudo apt-get dist-upgrade
|
||||
[user@kali-rolling ~]$ sudo apt-get autoremove
|
||||
|
||||
6. Shut down and trim the new template.
|
||||
|
||||
The last command should return `OK` on a line by itself.
|
||||
[user@dom0 ~]$ qvm-shutdown kali-rolling
|
||||
[user@dom0 ~]$ qvm-trim-template kali-rolling
|
||||
|
||||
5. Update the system:
|
||||
7. Ensure a terminal can be opened in the new template.
|
||||
|
||||
# in kali-tpl:
|
||||
sudo -s
|
||||
apt-get update && apt-get dist-upgrade
|
||||
[user@dom0 ~]$ qvm-run -a kali-rolling gnome-terminal
|
||||
|
||||
6. Shut down the `kali-tpl` template:
|
||||
|
||||
# in dom0:
|
||||
qvm-shutdown kali-tpl
|
||||
|
||||
### Install the Kali tools
|
||||
### Install the Kali tools ###
|
||||
|
||||
At this point you should have a working template and you can install the tools you need.
|
||||
|
||||
1. [resize the template] if you plan on installing the full Kali distribution. For example to install `kali-linux-full` you must **grow** the size of the VM system from 10Gb to at least 20Gb.
|
||||
1. [resize the template disk image][qubes-resize-disk-image] if you plan on installing the full Kali distribution. For example to install `kali-linux-full` you must **grow** the size of the VM system from 10GB to at least 20GB.
|
||||
|
||||
1. Install Kali linux:
|
||||
2. Install Kali Linux tools:
|
||||
|
||||
# in kali-tpl:
|
||||
sudo apt-get install kali-linux-full
|
||||
[user@kali-rolling ~]$ sudo apt-get install kali-linux-full
|
||||
|
||||
2. [optional] Customise the template's home directory (e.g. install your licensed copy of Burp Suite Professional)
|
||||
3. (Optional) Customise the template's home directory (e.g. install your licensed copy of Burp Suite Professional)
|
||||
|
||||
### Use the template
|
||||
### Use the template ###
|
||||
|
||||
The template is ready to be used. You can now spin up AppVMs based on the `kali-tpl` template.
|
||||
The template is ready to be used. You can now spin up AppVMs based on the `kali-rolling` template.
|
||||
|
||||
|
||||
|
||||
Alternative Options to Kali
|
||||
===========================
|
||||
Alternative Options to Kali Linux
|
||||
---------------------------------
|
||||
|
||||
* PenTester Framework: [PTF] ([PTF Qubes OS guide])
|
||||
* Black Arch with [BA Qubes OS guide])
|
||||
* [KATOOLIN]
|
||||
* [PenTester Framework][PTF], with [PTF Qubes OS guide][qubes-ptf]
|
||||
* BlackArch Linux, with [BA Qubes OS guide][qubes-blackarch]
|
||||
* [KATOOLIN][katoolin-howto]
|
||||
* more on the [Penetration Testing page][qubes-pentesting]
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
Thanks to the people in [the discussion thread].
|
||||
Thanks to the people in [the discussion thread](https://github.com/QubesOS/qubes-issues/issues/1981).
|
||||
|
||||
[qubes-verifying-signatures]: /security/verifying-signatures/
|
||||
[qubes-pentesting]: /doc/pentesting/
|
||||
[qubes-blackarch]: /doc/pentesting/blackarch/
|
||||
[qubes-ptf]: /doc/pentesting/ptf/
|
||||
[qubes-pentesting]: /doc/pentesting/
|
||||
[qubes-template-debian-install]: /doc/templates/debian/#install
|
||||
[qubes-resize-disk-image]: /doc/resize-disk-image/
|
||||
|
||||
[kali-vbox]: https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/
|
||||
[kali]: https://www.kali.org/
|
||||
[kali website]: https://docs.kali.org/introduction/download-official-kali-linux-images.
|
||||
[KATOOLIN]: http://www.tecmint.com/install-kali-linux-tools-using-katoolin-on-ubuntu-debian/
|
||||
[the debian-8 template]: https://www.qubes-os.org/doc/templates/debian/#install
|
||||
[kali-vbox]: https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/
|
||||
[kali website]: https://docs.kali.org/introduction/download-official-kali-linux-images
|
||||
|
||||
[PTF]: https://www.trustedsec.com/may-2015/new-tool-the-pentesters-framework-ptf-released/
|
||||
[audio CDs]: https://www.reddit.com/r/Nirvana/comments/3hmra1/the_main_character_in_the_tv_show_mr_robot_has_a/
|
||||
[resize the template]: https://www.qubes-os.org/doc/resize-disk-image/
|
||||
[the Debian wiki]: https://wiki.debian.org/Qubes#Install_Debian_Templates
|
||||
[the discussion thread]: https://github.com/QubesOS/qubes-issues/issues/1981
|
||||
[PTF Qubes OS guide]: https://www.qubes-os.org/doc/pentesting/ptf/
|
||||
[BA Qubes OS guide]: https://www.qubes-os.org/doc/pentesting/blackarch/
|
||||
|
||||
[katoolin]: https://github.com/LionSec/katoolin
|
||||
[katoolin-howto]: http://www.tecmint.com/install-kali-linux-tools-using-katoolin-on-ubuntu-debian/
|
||||
|
||||
@ -38,6 +38,7 @@ If you're a Signal user on Android, you can now have Signal inside Qubes.
|
||||
this app with your phone.
|
||||
6. Signal should now work in your AppVM.
|
||||
|
||||
|
||||
Creating a Shortcut in the applications menu
|
||||
--------------------------------------------
|
||||
|
||||
@ -76,8 +77,66 @@ You can now launch the Signal messenger inside its own dedicated AppVM directly
|
||||
|
||||
The same steps should work for any Chrome app.
|
||||
|
||||
Creating a shortcut in the applications menu for a StandaloneVM
|
||||
---------------------------------------------------------------
|
||||
|
||||
If you want to add to the standalone VM rather than a template, then follow below.
|
||||
The following part will also assume that the .desktop file has been correctly made.
|
||||
This can also be used to add a application portable application/script from a tar archive, also this part of the guide is assuming that the StandaloneVM is called `Signal`.
|
||||
|
||||
1. First you will need to copy/move the .desktop file: `/home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop`to the applications folder on the StandaloneVM: `/usr/share/applications/`
|
||||
|
||||
[user@Signal ~]$ sudo mv /home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop /usr/share/applications/
|
||||
|
||||
2. Now copy/move over the icon file to make it look all nice and pretty.
|
||||
|
||||
[user@Signal ~]$ sudo mv /home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop /usr/share/icons/hicolor/48x48/apps/
|
||||
|
||||
3. Now fire up the `dom0` Terminal Emulator from `Q` Menu -> `Terminal Emulator`. All you need to do now is run the command to sync the app menus `qvm-sync-appmenus` along with the Standalone VM name `Signal`.
|
||||
|
||||
[user@dom0 ~]$ qvm-sync-appmenus Signal
|
||||
|
||||
4. Now stop the StandaloneVM: `Signal`.
|
||||
|
||||
5. With your mouse select the `Q` menu -> `Domain: Signal` -> `Signal: Add more shortcuts`. Select `Signal Private Messenger` from the left `Available` column, move it to the right `Selected` column by clicking the `>` button and then `OK` to apply the changes and close the window.
|
||||
|
||||
6. (optional, only on KDE:) Follow the `Q` menu once more, right-click on the new `Signal: Signal Private Messenger` menu item and select `Add to Panel`.
|
||||
|
||||
Use an AppVM based on Debian
|
||||
----------------------------
|
||||
|
||||
**CAUTION:** Before proceeding, please carefully read [On Digital Signatures and Key Verification][qubes-verifying-signatures].
|
||||
This website cannot guarantee that any PGP key you download from the Internet is authentic.
|
||||
Always obtain a trusted key fingerprint via other channels, and always check any key you download against your trusted copy of the fingerprint.
|
||||
|
||||
If you don't use Chromium, you can install signal with Debian:
|
||||
|
||||
1. (Optional)Create a TemplateVM (Debian 8)
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
|
||||
|
||||
2. Open a terminal in Debian 8
|
||||
|
||||
[user@dom0 ~]$ qvm-run -a debian-8 gnome-terminal
|
||||
|
||||
3. Use these commands in your terminal
|
||||
|
||||
(Optional)[user@debian-8 ~]$ sudo apt-get install curl
|
||||
[user@debian-8 ~]$ curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
|
||||
[user@debian-8 ~]$ echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
|
||||
[user@debian-8 ~]$ sudo apt update && sudo apt install signal-desktop
|
||||
|
||||
5. Shutdown the TemplateVM :
|
||||
|
||||
[user@dom0 ~]$ qvm-shutdown debian-8
|
||||
|
||||
6. Create an AppVM based on this TemplateVM
|
||||
7. With your mouse select the `Q` menu -> `Domain: "AppVM Name"` -> `"AppVM Name": Add more shortcuts`
|
||||
Select `Signal` from the left `Available` column, move it to the right `Selected` column by clicking the `>` button and then `OK` to apply the changes and close the window.
|
||||
|
||||
-----
|
||||
|
||||
[qubes-verifying-signatures]: /security/verifying-signatures/
|
||||
[Signal]: https://whispersystems.org/
|
||||
[signal-wikipedia]: https://en.wikipedia.org/wiki/Signal_(software)
|
||||
[shortcut]: https://support.whispersystems.org/hc/en-us/articles/216839277-Where-is-Signal-Desktop-on-my-computer-
|
||||
|
||||
@ -23,31 +23,26 @@ 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](/doc/whonix/install/)
|
||||
* Note: To install Whonix in Qubes, you must already have a working Qubes machine.
|
||||
* [Installing Whonix in Qubes](/doc/whonix/install/)
|
||||
* [Updating Whonix in Qubes](/doc/whonix/update/)
|
||||
|
||||
## Customizing, Reinstalling, & Uninstalling Whonix
|
||||
|
||||
* [Customizing Whonix](/doc/whonix/customize/)
|
||||
* [Uninstall Whonix from Qubes](/doc/whonix/uninstall/)
|
||||
* [Uninstalling Whonix from Qubes](/doc/whonix/uninstall/)
|
||||
|
||||
*The following links are on Whonix's website and may be technical.*
|
||||
*The following pages are written by the Whonix developers and are located on their website.*
|
||||
|
||||
* [Using Whonix with DisposableVMs](https://www.whonix.org/blog/qubes-whonix-dispvm)
|
||||
* [Security Advice for after installing Whonix on Qubes](https://www.whonix.org/wiki/Post_Install_Advice)
|
||||
* [Post-Installation Security Advice](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)
|
||||
* [How to use Corridor (a Tor traffic whitelisting gateway) with Whonix](https://www.whonix.org/wiki/Corridor)
|
||||
|
||||
## Support for Whonix
|
||||
|
||||
*The following links are on Whonix's site.*
|
||||
*The following pages are written by the Whonix developers and are located on their website.*
|
||||
|
||||
* [Whonix Support](https://www.whonix.org/wiki/Support) - General Whonix, Debian, Tor, etc... related issues
|
||||
* [Whonix Qubes Forum](https://forums.whonix.org/c/qubes) - Whonix specific issues
|
||||
|
||||
You can also use [Qubes support](/help/), but not all Qubes users run Whonix.
|
||||
|
||||
|
||||
@ -17,3 +17,6 @@ This schedule is based on [Version Scheme](/doc/version-scheme/#release-schedule
|
||||
| <strike>28 Aug 2017</strike><br/><strike>11 Sep 2017</strike><br/><strike>9 Oct 2017</strike><br/>18 Oct 2017 | current-testing freeze before 4.0-rc2 |
|
||||
| <strike> 4 Sep 2017</strike><br/><strike>18 Sep 2017</strike><br/><strike>16 Oct 2017</strike><br/>23 Oct 2017 | 4.0-rc2 release |
|
||||
| 6 Nov 2017 | decide whether 4.0-rc2 is the final 4.0 |
|
||||
| 20 Nov 2017 | current-testing freeze before 4.0-rc3 |
|
||||
| 27 Nov 2017 | 4.0-rc3 release |
|
||||
| 11 Dec 2017 | decide whether 4.0-rc3 is the final 4.0 |
|
||||
|
||||
@ -17,6 +17,7 @@ redirect_from:
|
||||
Qubes OS Project Security Center
|
||||
================================
|
||||
|
||||
- [Security FAQ](/faq/#general--security)
|
||||
- [Security Goals](/security/goals/)
|
||||
- [Security Pack](/security/pack/)
|
||||
- [Security Bulletins](/security/bulletins/)
|
||||
|
||||
@ -16,9 +16,9 @@ The Role of the Firewall
|
||||
|
||||
**[Firewalling in Qubes](/doc/firewall/) is not intended to be a leak-prevention mechanism.**
|
||||
|
||||
There are several reasons for this, which will be explained below. However, the main reason is that Qubes cannot prevent an attacker who has compromised one AppVM (with restrictive firewall rules) from leaking data via cooperative covert channels through a different AppVM (with sufficiently nonrestrictive firewall rules, if any) which the attacker has also compromised.
|
||||
There are several reasons for this, which will be explained below. However, the main reason is that Qubes cannot prevent an attacker who has compromised one AppVM with restrictive firewall rules from leaking data via cooperative covert channels through another compromised AppVM with nonrestrictive firewall rules.
|
||||
|
||||
For example, suppose you have an `email` AppVM. You have set the firewall rules for `email` such that it can communicate only with your email server. Now suppose that an attacker sends you a GPG-encrypted message which exploits a hypothetical bug in the GnuPG process. There are now multiple ways the attacker could proceed to leak data (such as confidential email messages) from `email`. The most obvious way is by simply emailing the data to himself. Another possibility is that the attacker has also compromised another one of your AppVMs, such as your `netvm`, which is normally assumed to be untrusted and has unrestricted access to the network. In this case, the attacker might move data from `email` to the `netvm` via a covert channel, such as the CPU cache. Such covert channels through the CPU cache have been described and even implemented in some "lab environments" and might allow for bandwidths of even a few tens of bits/sec. It is unclear whether such channels could be implemented in a real world system, where multiple VMs execute at the same time, each running tens or hundreds of processes, all using the same cache memory, but it is worth keeping in mind. Of course, this would require special malware written specifically to attack Qubes OS, and perhaps even a specific Qubes OS version and perhaps a specific Qubes OS configuration. Nevertheless, it might be possible.
|
||||
For example, suppose you have an `email` AppVM. You have set the firewall rules for `email` such that it can communicate only with your email server. Now suppose that an attacker sends you a GPG-encrypted message which exploits a hypothetical bug in the GnuPG process. There are now multiple ways the attacker could proceed to leak data (such as confidential email messages) from `email`. The most obvious way is by simply emailing the data to himself. Another possibility is that the attacker has also compromised another one of your AppVMs, such as your `netvm`, which is normally assumed to be untrusted and has unrestricted access to the network. In this case, the attacker might move data from `email` to the `netvm` via a covert channel, such as the CPU cache. Such covert channels have been described and even implemented in some "lab environments" and might allow for bandwidths of even a few tens of bits/sec. It is unclear whether such channels could be implemented in a real world system, where multiple VMs are running at the same time, each handling tens or hundreds of processes, all using the same cache memory, but it is worth keeping in mind. Of course, this would require special malware written specifically to attack Qubes OS, and perhaps even a specific Qubes OS version and/or configuration. Nevertheless, it might be possible.
|
||||
|
||||
Note that physically air-gapped machines are not necessarily immune to this problem. Covert channels can potentially take many forms (e.g., sneakernet thumb drive, bluetooth, or even microphone and speakers).
|
||||
|
||||
@ -29,12 +29,12 @@ Types of Data Leaks
|
||||
|
||||
In order to understand and attempt to prevent data leaks in Qubes, we must distinguish among three different types of relevant data leaks:
|
||||
|
||||
1. **Intentional leaks.** Malicious software which actively tries to leak data out of an AppVM, perhaps via cooperative covert channels established with other malicious software in another AppVM (or on some server via networking, if networking, even limited, is allowed for the AppVM).
|
||||
1. **Intentional leaks.** Malicious software which actively tries to leak data out of an AppVM, perhaps via cooperative covert channels established with other malicious software in another AppVM or on some server via networking, if networking, even limited, is allowed for the AppVM.
|
||||
|
||||
1. **Intentional sniffing.** Malicious software trying to use side channels to, e.g., actively guess some key material used in another VM by some non-malicious software there (e.g., non-leak-proof GPG accidentally leaking out bits of the private key by generating some timing patterns when using this key for some crypto operation). Such attacks have been described in the academic literature, but it is doubtful that they would succeed in practice in a moderately busy general purpose system like Qubes OS (where the attacker normally has no way to trigger the target crypto operation explicitly, and it is normally required that the attacker trigger many such operations).
|
||||
2. **Intentional sniffing.** Malicious software trying to use side channels to, e.g., actively guess some key material used in another VM by some non-malicious software there (e.g., non-leak-proof GPG accidentally leaking out bits of the private key by generating some timing patterns when using this key for some crypto operation). Such attacks have been described in the academic literature, but it is doubtful that they would succeed in practice in a moderately busy general purpose system like Qubes OS where the attacker normally has no way to trigger the target crypto operation explicitly and it is normally required that the attacker trigger many such operations.
|
||||
|
||||
1. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data (whether by design or accident). For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
|
||||
3. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data, whether by design or accident. For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
|
||||
|
||||
Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an AppVM to "none") can fully protect against leaks of type 3. However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2. It is likely that the only way to fully protect against leaks of type 1 and 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
|
||||
Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an AppVM to "none") can fully protect against leaks of type 3. However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2. There are few effective, practical policy measures available to end-users today to stop the leaks of type 1. It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
|
||||
|
||||
For further discussion, see [this thread](https://groups.google.com/d/topic/qubes-users/t0cmNfuVduw/discussion).
|
||||
|
||||
@ -129,7 +129,7 @@ It is preferable to avoid using **Bluetooth** if you travel or do not trust your
|
||||
|
||||
Many laptops allow one to disable various hardware (Camera, BT, Mic, etc) **in BIOS**. This might or might not be a dependable way of getting rid of those devices, depending on how much you trust your BIOS vendor.
|
||||
|
||||
If the VM will not start after you have assigned a USB controller, look at [this faq](../user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot).
|
||||
If the VM will not start after you have assigned a USB controller, look at [this FAQ](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot).
|
||||
|
||||
|
||||
Creating and Using a USBVM
|
||||
|
||||
@ -17,30 +17,26 @@ A "split" bitcoin wallet is a strategy of protecting your bitcoin by having your
|
||||
A "Watching" Wallet and a "Cold" Wallet
|
||||
---------------------------------------
|
||||
|
||||
1. Create a Debian 8 backports template using the Qubes VM Manager or running
|
||||
`qvm-clone debian-8 debian-8-backports` in dom0.
|
||||
1. Create a fedora-25-electrum template using the Qubes VM Manager or running
|
||||
`qvm-clone fedora-25 fedora-25-electrum` in dom0.
|
||||
|
||||
2. Add backports to the sources for the new template by opening a terminal in
|
||||
the new template, run `sudo vi /etc/apt/sources.list` and add
|
||||
`deb http://http.debian.net/debian jessie-backports main`.
|
||||
2. Start the new template:
|
||||
`qvm-start fedora-25-electrum`
|
||||
`qvm-run fedora-25-electrum xterm`
|
||||
|
||||
(If you are new to `vi` text editing, type `i` to be able to edit, and when
|
||||
done editing press `ESC` then type `:x` and press `ENTER`.)
|
||||
3. Install `electrum` to fedora-25-electrum template VM. From fedora-25-electrum terminal enter:
|
||||
`sudo dnf update`.
|
||||
`sudo dnf install electrum`.
|
||||
|
||||
3. Update source list: `sudo apt-get update`.
|
||||
4. Shut down your `fedora-25-electrum` template
|
||||
|
||||
4. Install `electrum` from backports:
|
||||
`sudo apt-get -t jessie-backports install electrum`.
|
||||
5. Create an `offline-bitcoin` qube based on `fedora-25-electrum` using the Qubes VM Manager or running `qvm-create -t fedora-25-electrum -l black offline-bitcoin` and `qvm-prefs -s offline-bitcoin netvm none` in dom0.
|
||||
|
||||
5. shut down your `debian-8-backports` template
|
||||
6. Follow the [electrum documentation in creating an offline wallet](http://docs.electrum.org/en/latest/coldstorage.html#create-an-offline-wallet)
|
||||
|
||||
6. create an `offline-bitcoin` qube based on `debian-8-backports` using the Qubes VM Manager or running `qvm-create -t debian-8-backports -l black offline-bitcoin` and `qvm-prefs -s offline-bitcoin netvm none` in dom0.
|
||||
7. Create a `watching-bitcoin` qubes based on `fedora-25-electrum` connecting to the internet how ever you prefer using the Qubes VM Manager or running for example `qvm-create -t fedora-25-electrum -l green watching-bitcoin` and `qvm-prefs -s watching-bitcoin netvm sys-whonix` in dom0.
|
||||
|
||||
7. follow the [electrum documentation in creating an offline wallet](http://docs.electrum.org/en/latest/coldstorage.html#create-an-offline-wallet)
|
||||
|
||||
8. create a `watching-bitcoin` qubes based on `debian-8-backports` connecting to the internet how ever you prefer using the Qubes VM Manager or running for example `qvm-create -t debian-8-backports -l green watching-bitcoin` and `qvm-prefs -s watching-bitcoin netvm sys-whonix` in dom0.
|
||||
|
||||
9. follow the [electrum documentation in creating an online watching-only wallet](http://docs.electrum.org/en/latest/coldstorage.html#create-a-watching-only-version-of-your-wallet)
|
||||
8. Follow the [electrum documentation in creating an online watching-only wallet](http://docs.electrum.org/en/latest/coldstorage.html#create-a-watching-only-version-of-your-wallet)
|
||||
|
||||
Important Notes
|
||||
---------------
|
||||
|
||||
@ -11,7 +11,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).
|
||||
risk of snooping the password. This can also slightly improve security when you have [USB keyboard](https://www.qubes-os.org/doc/usb/#security-warning-about-usb-input-devices).
|
||||
|
||||
There (at least) two possible configurations: using OTP mode and using challenge-response mode.
|
||||
|
||||
@ -88,9 +88,13 @@ To use this mode you need:
|
||||
|
||||
### Usage
|
||||
|
||||
When you want to unlock your screen, plug YubiKey into USB slot, then enter
|
||||
password associated with YubiKey. If you configured so, YubiKey will request
|
||||
confirmation by pressing button on it (it will blink).
|
||||
When you want to unlock your screen...
|
||||
|
||||
1) Plug YubiKey into USB slot.
|
||||
2) Enter password associated with YubiKey.
|
||||
3) Press Enter.
|
||||
4) If you configured so, YubiKey will request confirmation by pressing button on it (it will blink).
|
||||
|
||||
When everything is ok, your screen will be unlocked.
|
||||
|
||||
In any case you can still use your login password, but do it in secure location
|
||||
@ -104,7 +108,9 @@ YubiKey. This will require creating simple qrexec service which will expose
|
||||
ability to lock the screen to your USB VM, and then adding udev hook to
|
||||
actually call that service.
|
||||
|
||||
1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0)
|
||||
In dom0:
|
||||
|
||||
1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen`
|
||||
with simple command to lock the screen. In case of xscreensaver (used in Xfce)
|
||||
it would be:
|
||||
|
||||
@ -115,7 +121,9 @@ would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
|
||||
|
||||
sys-usb dom0 allow
|
||||
|
||||
3. Create udev hook in your USB VM. Store it in `/rw/config` to have it
|
||||
In your USB VM:
|
||||
|
||||
3. Create udev hook. Store it in `/rw/config` to have it
|
||||
persistent across VM restarts. For example name the file
|
||||
`/rw/config/yubikey.rules`. Write there single line:
|
||||
|
||||
@ -126,8 +134,13 @@ persistent across VM restarts. For example name the file
|
||||
ln -s /rw/config/yubikey.rules /etc/udev/rules.d/
|
||||
udevadm control --reload
|
||||
|
||||
Then make `/rw/config/rc.local` executable. For changes to take effect, you
|
||||
need to call this script manually for the first time.
|
||||
5. Then make `/rw/config/rc.local` executable.
|
||||
|
||||
sudo chmod +x /rw/config/rc.local
|
||||
|
||||
6. For changes to take effect, you need to call this script manually for the first time.
|
||||
|
||||
sudo /rw/config/rc.local
|
||||
|
||||
If you use KDE, the command(s) in first step would be different:
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ Qubes Dom0 secure update procedure
|
||||
Reasons for Dom0 updates
|
||||
------------------------
|
||||
|
||||
Normally there should be few reasons for updating software in Dom0. This is because there is no networking in Dom0, which means that even if some bugs will be discovered e.g. in the Dom0 Desktop Manager, this really is not a problem for Qubes, because all the 3rd party software running in Dom0 is not accessible from VMs or network in any way. Some exceptions to the above include: Qubes GUI daemon, Xen store daemon, and disk back-ends (we plan move the disk backends to untrusted domain in Qubes 2.0). Of course we believe this software is reasonably secure and we hope it will not need patching.
|
||||
Normally there should be few reasons for updating software in Dom0. This is because there is no networking in Dom0, which means that even if some bugs will be discovered e.g. in the Dom0 Desktop Manager, this really is not a problem for Qubes, because all the 3rd party software running in Dom0 is not accessible from VMs or network in any way. Some exceptions to the above include: Qubes GUI daemon, Xen store daemon, and disk back-ends (we plan to move the disk backends to untrusted domain in Qubes 2.0). Of course we believe this software is reasonably secure and we hope it will not need patching.
|
||||
|
||||
However, we anticipate some other situations when updating Dom0 software might be required:
|
||||
|
||||
@ -25,20 +25,20 @@ However, we anticipate some other situations when updating Dom0 software might b
|
||||
Problems with traditional network-based update mechanisms
|
||||
---------------------------------------------------------
|
||||
|
||||
Dom0 is the most trusted domain on Qubes OS, and for this reason we decided to design Qubes in such a way that Dom0 is not connected to any network. In fact only select domains can be connected to a network via so called network domains. There could also be more than one network domain, e.g. in case the user is connected to more than one physically or logically separated networks.
|
||||
Dom0 is the most trusted domain on Qubes OS, and for this reason we decided to design Qubes in such a way that Dom0 is not connected to any network. In fact only certain domains can be connected to a network via so-called network domains. There can also be more than one network domain, e.g. in case the user is connected to more than one physically or logically separated networks.
|
||||
|
||||
Secure update mechanism we use in Qubes (starting from Beta 2
|
||||
Secure update mechanism we use in Qubes (starting from Beta 2)
|
||||
-------------------------------------------------------------
|
||||
|
||||
Keeping Dom0 not connected to any network makes it hard, however, to provide updates for software in Dom0. For this reason we have come up with the following mechanism for Dom0 updates, which minimizes the amount of untrusted input processed by Dom0 software:
|
||||
|
||||
The update process is initiated by [qvm-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0.
|
||||
|
||||
Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
|
||||
Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and fetch maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
|
||||
|
||||
Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
|
||||
|
||||
The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input.
|
||||
The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input).
|
||||
|
||||
Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user