the workspaces.
Was an Operating System really needed? Couldn’t they create three virtual
machines instead? Sure, but the three VMs would have required three operating
systems, each consuming hardware resources, requiring updates and so on.
10.2.1.1 Virtualization logic
The Qubes built-in hypervisor allows to create unlimited qubes using a
single Operating System,
which natively supports Fedora, Debian, Windows
(after installing the latter
[146]
) and Whonix; furthermore the workspaces share
the same graphic environment, thus eliminating the annoying switch from an OS
to another and vice versa. You may also have noticed that the three workspaces
are color-coded; the same happens with the graphical level (Figure 48).
Figure 48: working logic of Qubes virtualized environments
As you can see, the three windows are represented by a different color, just
like the infographics.
Additionally, only one is bright, while the others are
slightly shaded.
Qube OS allows to immediately recognize the workspaces breaking them
down by color, as well as to show the ones you’re working on in real time,
highlighting the application that can inter-communicate. And when a VM is
closed, all the temporary data it generated is erased.
10.2.1.2 Network and Storage Domains
As we noticed, the Network environment is the most harmful for user
wishing to protect their anonymity.
Qubes OS provides a virtualization system called Network Domain:
essentially, the VM concept is also applied to the network, which is virtualized in
an environment controlled by a pseudo-user without
root privileges and isolated
from the rest of the Operating System. Consequently, it’s like all the networking
operations (website linking, downloads, chat and so on) are managed by another
Virtual Machine, which is not able to impact the primary machine, ensuring an
unprecedented security, since the users won’t be exposed to network-level
attacks.
The same applies to data storage, here defined as Storage Domain:
workspaces must have their own disk space, obviously,
in order to memorize
software, data and whatnot. All the pseudo-partition share the same file system
in read-only mode, thus avoiding compromises, and centralizing updates at the
same time. By default, the entire file system comes already encrypted during the
first installation.
10.2.1.3 Why use Qubes and not Tails OS?
As usual, let’s assume that everyone will choose their preferred solution:
users who prefer Tails will be probably looking for a scenario that’s totally
different than their usual, day-by-day tasks; Tails, in fact, allows to have a safe
environment, applicable to the most common anonymous navigation operations;
usability, however, is both its intrinsic limitation and main strength. Like many
other
Live distros, Tails OS is designed for hit-and-run operations that are not
always ideal for your typical tasks.
An expert GNU/Linux user may need the security offered by Tails (as far as
possible) together with the possibility of relying on a convenient environment, in
order to work without having to reboot the Operation System every time. Qubes
OS is the answer to such need, ensuring both isolated workspaces and the
convenience of a standalone Operating System. Since it’s all about individual
choices, comparing features and electing the best solution would be pointless.
The bottom line is: both the Operating Systems are good for their purposes.
-
Tails is designed to
stay anonymous. When launched in a computer, it
works so that no traces are left in it, changing the network adapter Mac Address
and redirecting all the traffic to TOR.
-
Qubes
is designed for everyday use. The final goal is to protect the user
against any type of cyber attacks. It comes without any anonymity tools by
default (except the Whonix integration), so it has to be customized by the final
user.
10.2.2 Qubes OS + Tais
I guess you got disappointed when I said that Qubes is not an anonymity-
designed Operating System, and you wondered: “so, why are you mentioning
it?”. But, then, reading the title of this chapter you may have got excited, or
(more probably) looked back to my statement: “hey, don’t use Tails on Virtual
Machines!”, therefore I have to give you a reply.
It’s true that Tails should not be used in VMs, and I already explained the
reasons why, the same stated by the developers: the most important is the
persistence – or, better, reminiscence –
of Operating System data, which remain
stored in the disk. As we saw, however, Qubes uses a para-virtualization logic
that completely destroys the stored data, thus facilitating the drive sanitation
tasks. Consequently, the Qubes OS environment is fit for Tails virtualization, and
the related steps are quite easy to follow
[147]
. This way, you can leverage the
power of Qubes OS together with Tails OS – as they say,
killing two birds with
one stone!
10.2.3 Qubes OS + Whonix
Using Tails in Qubes allowed us to understand how to virtualize a full
Operating System within a Xen para-virtualized system; this, however, can be
considered as a limit, becoming reality when you want to use the tools in Qubes
instead of the ones virtualized in Tails.
Furthermore, only the Tails environment ensures enough security to maintain
your Anonymity. Then, we need to create a further level (just like we saw with
the Network and Storage Domains), allowing us to redirect traffic to a safe and
anonymous communication channel. Whonix is another GNU/Linux distro based
on Debian and Tor that leverages two Virtual Machines: a
Gateway and a
Do'stlaringiz bilan baham: 
