I got qubes installed, have some questions

[boromi...@sigaint.org]

I tooled around in 3.1 and got the basic understanding that you arent
running OS VMs like vmware but instead app VM's, but im not familiar with
how these work in respect to isolation.

If i am running two app vms under the same template and one app gets
infected, does everything in that template get infected?

I am running a disposable app vm and i assume its infected, is it possible
to retrieve files from it without cross contamination? Where are the
instructions on how to do this?

Is there a way to set my printer to be preconfigured when spawning vm's so
i dont have to configure it everytime?

How do i install a program so that it is availble to other templates?

In respect to network functions, i see that there is the whonix gw, and
the sys-gw, and it appears i can spawn other gw's, assuming these are all
running Tor how do i prevent Tor->Tor-Tor etc... from happening? How do i
determine which vm is using which gw?

Id like qubes to be universally torified but then there may be times where
i need to spawn a clearnet vm alongside a torified vm, how do i configure
this?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-22 11:52, boromi...@sigaint.org wrote:
>
> I tooled around in 3.1 and got the basic understanding that you
> arent running OS VMs like vmware but instead app VM's, but im not
> familiar with how these work in respect to isolation.
>
> If i am running two app vms under the same template and one app
> gets infected, does everything in that template get infected?
>

No, each AppVM has only read-only access to its TemplateVM. A
compromised TemplateVM can compromise all AppVMs based on it, but not
vice versa. Furthermore, two AppVMs do not pose any risk to each other
merely in virtue of sharing the same TemplateVM.

More information:

https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-3

> I am running a disposable app vm and i assume its infected, is it
> possible to retrieve files from it without cross contamination?
> Where are the instructions on how to do this?
>

It's not really possible to answer that question in the abstract. It
always depends on the situation, and in general it is difficult to do
and almost always impossible to verify.

One case Qubes currently supports its the trusted PDF converter. This
is a reasonably secure way to produce a trusted PDF from one which is
untrusted.

> Is there a way to set my printer to be preconfigured when spawning
> vm's so i dont have to configure it everytime?
>

Yes. In general, you should be able to configure it in the TemplateVM,
then have it work in any AppVM based on this template. However, the
new AppVMs may have to be created after the configuration in the
TemplateVM is completed, depending on where files are stored, since
changes to certain directories in the TemplateVM do not propagate to
AppVMs which already exist.

You can read more about this here:

https://www.qubes-os.org/doc/templates/#tocAnchor-1-1-3

> How do i install a program so that it is availble to other
> templates?
>

You cannot do this by design. If you want a program to be available in
two templates, you must install it in both templates.

The reason for this is that if it were possible for an installed
program to be available to other templates, then a single malicious
program could potentially compromise every template in a Qubes
installation, and therefore every TemplateBasedVM in the system, which
would almost entirely defeat the point of Qubes (security by
compartmentalization).

> In respect to network functions, i see that there is the whonix gw,
> and the sys-gw, and it appears i can spawn other gw's, assuming
> these are all running Tor how do i prevent Tor->Tor-Tor etc... from
> happening? How do i determine which vm is using which gw?
>

Did you mean "sys-net" instead of "sys-gw"? There should be no
"sys-gw" by default.

Unless you configure things in a special way, generally only ProxyVMs
based on whonix-gw will route traffic through Tor. If you choose to
create one by default, it will be called "sys-whonix". sys-net will
generally be a clearnet (non-Tor) connection to your local network,
and sys-firewall will generally be a ProxyVM for enforcing firewall
rules. The typical network topology looks something like this:

personal -------------------
\
work ------------------------> sys-firewall ---> sys-net
/
anon-web ---> sys-whonix ---

In this sort of setup, there will be no Tor-over-Tor traffic.

You can see what a VM's NetVM is by right-clicking it in Qubes
Manager, clicking "VM settings," and reading the "NetVM" box.

> Id like qubes to be universally torified but then there may be
> times where i need to spawn a clearnet vm alongside a torified vm,
> how do i configure this?
>

As mentioned above, you can set the NetVMs of any desired VMs to
"sys-whonix" (or another ProxyVM based on whonix-gw) in order to
Torify all traffic from those VMs.

In order to cause a VM's traffic to use your clearnet connection, set
its NetVM to "sys-firewall" (again, assuming the default setup).

For update checks, you may wish to disable automatic template checks
for any templates with child AppVMs using clearnet connections. (Those
update checks are done by the child AppVMs, so if you don't want those
update checks go out in the clear, disable them.) For dom0 updates,
you can create or select a ProxyVM which uses sys-whonix as its NetVM,
then go into the global settings in Qubes Manager and select that as
the UpdateVM.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXQoG8AAoJENtN07w5UDAwzNgP/26yTwDnNCpLX8vwhmchowpM
s8bAckJsxhFg9Sr0qm/wTA1M6I9TyTOrCLEHHULk+pnc+uZKRdrfwR9VJnzZIstb
9kQvA9JGNXCBunmQInToZc7nyIAAJsD9/pPkcxA6oNtml3SGfsZNQwTZFTHhzu8H
cSKhM7SYaU+qdJLHCr+ByViwGASj4wYanb3F5PsHsFHihMjVLkqytvfpbQPs/SCE
LcG4Oe79aYDWkDEUSecyXgaeG9pDQ/8FHrmg/8JpkZLNgBzRwlZ8U14dMzetmw6n
WwlQyrCHGAeslw+xs7epEuhK0DxbPpaWDIIk5U3iiu6rTGgaE2tjSvdsBoS74pdh
JA+QLguk5BDG7ngBURn4vLCUQZkRh3/OUpmcCxTZmzuItRo/Bsml11j4Jd+2b73K
NRlx5GUiXv3TBOqrrFMMUL22w1f6nz2bh5sUTCkey1kM0h9WjBKsgYvrOSE7sZsx
N9SD/FamH6KaagH+LQgmbQgjqTB58cwEFTwUwdCrUykBk/cv1Cqg0XFHWQMbIPvP
UzBHAGni6Ky9h3U1UdzJyAyadyP5P+R3hnxAHlna8nWrJglZYIQP3LqW8esrPtbr
JUa9wfBqFTr2iMrdJ7HpbC6Wxg5rOm3W89a5sR8SMvvanUiHRlwD5Oe/qPFQ2xzW
Gon1PQfoVEwaWg1srEGB
=ww6E
-----END PGP SIGNATURE-----

[Chris Laprise]

On 05/23/2016 12:06 AM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-05-22 11:52, boromi...@sigaint.org wrote:
>> I tooled around in 3.1 and got the basic understanding that you
>> arent running OS VMs like vmware but instead app VM's, but im not
>> familiar with how these work in respect to isolation.
>>
>> If i am running two app vms under the same template and one app
>> gets infected, does everything in that template get infected?
>>
> No, each AppVM has only read-only access to its TemplateVM. A
> compromised TemplateVM can compromise all AppVMs based on it, but not
> vice versa. Furthermore, two AppVMs do not pose any risk to each other
> merely in virtue of sharing the same TemplateVM.
>
> More information:
>
> https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-3
>
>> I am running a disposable app vm and i assume its infected, is it
>> possible to retrieve files from it without cross contamination?
>> Where are the instructions on how to do this?
>>
> It's not really possible to answer that question in the abstract. It
> always depends on the situation, and in general it is difficult to do
> and almost always impossible to verify.

Suspect files can be safely handled with qvm-copy between vms, as long
as no attempts are made to open them (even parsing them can be risky).
But the act of retrieval itself should be considered safe.

This is in contrast to something like a USB drive that gets mounted in
different vms to move/retrieve data: The filesystem itself poses a risk
in that case.



Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

IIUC:

1. We have to trust the compromised VM to qvm-copy the same file we
ask it to. It may appear to comply but in reality copy a malicious
file to the destination VM.

2. Since the copied file may have been modified to be or replaced with
a malicious file, opening it in the new, clean VM could result in
cross-contamination.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXQ4ryAAoJENtN07w5UDAwQq8QAIWFT9M+CU3pYP8Wu3l9kSFp
2pz/CeRK0DbqKreODuBY8KMmZ96Y3jiiNBOfqvu5tLUSieKqwr/tMRj02NC8xJOI
t48pKfW3hKO8jHMShtlKI/hPK1abILzQAuE4nJYrttQRTuYGax8IBTR4pMrF/rw0
ZU2uN1H4Tf0MsFr9nJwkxZWnNsnS6SxLCd7ComhUY1H2b91oaQH5BxQ3pasFbZ7W
AtJsChH8vNRpZl8c75VB3TvaNCDBJcso8YRC0f+q0PnXI/BCOPVmJNHSyZyXeP/A
zr2k+cUQN0/Z5xye9eaNL6dQuWJAYEytswYbFwZzaqGd+AJ1MsbboUnJZQTC/Poh
zJ7WOAmXOAMHE1/34UmAZBMQSk4KM4ukdXrRE4rIuLG9V9/ztWHsjPyAp0UAcw3i
ZghfS4+vb8HF5VSJcgky157LT74BlUaA3Pr1I7mA3CuAPM4/5GoRtth4iT+1QGLw
129c69E50PxtgGQHLQg3uAnfw/KXDVcxBRmSnUU91jJaV7FJCA0TA/Y62TRDPW+2
2rGjtINmj5QkSfxOLIxoW/qQP/b+koTPO9zf/+wNs719bujaGS3wo3qrPUY0RXa6
y9jOIppDo0fLCDTWeyoDY6s6dkcOvSpjCo/P+EUXZKxTDkr8GdOL68OmntrswrJV
xtcj484fscVAULti0BxJ
=Gbca
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

1. Please don't top post.
2. Please keep the list CCed unless there's a need for privacy (in
which case, use PGP).

On 2016-05-23 14:00, boromi...@sigaint.org wrote:
> What is the difference between sys-whonix and whonix-gw? I thought
> the gw was the torified proxy, so what is sys-whonix?
>

sys-whonix is the Torifying ProxyVM based on whonix-gw. whonix-gw is
the TemplateVM on which sys-whonix is based.

> I tried to set my bridge node but it gave me a error that whonix
> doesnt support bridge nodes (and i thought tails was sketchy for
> not having this basic anonymity feature). I have to edit torrc in
> tails to set it but i dont see where this file is in whonix, and
> then i dont know if im supposed to look for it in whonix-gw or
> sys-whonix.
>

https://www.whonix.org/wiki/Bridges#How_to_use_bridges_in_Whonix

> Also there was another reply in response to my question about
> moving files out of a possibly compromised vm, you said this was
> difficult but they replied "Suspect files can be safely handled
> with qvm-copy between vms,". I am assuming that the vm environment
> is compromised but my file that i want to pull out of it is
> probably ok, is there a tutorial on how to move it?
>

qvm-copy-to-vm should be documented in its man page (which doesn't
exist in my installation...):

$ man qvm-copy-to-vm

and in the help:

$ qvm-copy-to-vm --help

and on the website here:

https://www.qubes-os.org/doc/vm-tools/qvm-copy-to-vm/


See my earlier reply for the other parts.

> On 2016-05-22 11:52, boromi...@sigaint.org wrote:
>>>>
>>>> I tooled around in 3.1 and got the basic understanding that
>>>> you arent running OS VMs like vmware but instead app VM's,
>>>> but im not familiar with how these work in respect to
>>>> isolation.
>>>>
>>>> If i am running two app vms under the same template and one
>>>> app gets infected, does everything in that template get
>>>> infected?
>>>>
>
> No, each AppVM has only read-only access to its TemplateVM. A
> compromised TemplateVM can compromise all AppVMs based on it, but
> not vice versa. Furthermore, two AppVMs do not pose any risk to
> each other merely in virtue of sharing the same TemplateVM.
>
> More information:
>
> https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-3
>
>>>> I am running a disposable app vm and i assume its infected,
>>>> is it possible to retrieve files from it without cross
>>>> contamination? Where are the instructions on how to do this?
>>>>
>
> It's not really possible to answer that question in the abstract.
> It always depends on the situation, and in general it is difficult
> to do and almost always impossible to verify.
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXQ45DAAoJENtN07w5UDAwtX8P/2kLZujLDjwLIZiSx1Ck+Mq0
f0WPWNQmdGDHVIqVr/Q7XwIMGJa3ZlpHTYwFwNXpN9tj1MUQQgxHJJG114dBj5uP
EC53i8Ck6SRy6THu8qNjyoRrC2axlObkiQS8orpwwlrFLHwXoAZDP8NE2aFzl199
+WSL/jalWFM+idqF4KkUqcddM+Y7EoxvsNO6uIMxMazZCNghtzg57kRNeqEBLPCY
KnT7qqXI0vl4yz1x+dYp01YVBAH7gglRth7DPZ+PoBqQGQ1crLB27uFm+iOJM9dC
txp3OexhAIyMlK0inR317n472+YrBsXxu39cemTfJ27+T2z9BikYzfVgnTfpBCqr
C0X/p/aQhK5ax3MLmTxI2SdwFE93Rf9Uj6qeZdspWpGZjdsc5GrTwRtf6gG4KHc5
04iKAg/G5DY/KMK8Uk2ebqPQwr/+TElBP0d8DQmLJzXM0oVjCkv1otr2IpRsnG+o
DR23SYzMAMWeQnREndryTarnD9z2ZrQC23tc5U7IVTR5H3in8zauEuS52iGtLJ1o
n9OifK938XdnPhEUzu20UCRTqldQx6EtwZzKzmxy3m1l3JhhZnUh5RmZc1gWInee
vbHowqY3SorZ9SPzVEthwitKfTpYaWOgrtH3f1P1znIvuKPhNezLTWxNkDVWPGs4
r0/KexVlLo2NP8ThrtD/
=mMMj
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> OK, so then how does one safely move a file they believe to not be
> contaminated from a contaminated vm to a clean one??
>
>
>
>

I repeat:

Please keep the list CCed unless there's a need for privacy (in
which case, use PGP).

I already answered your question in this very thread:

https://groups.google.com/d/msg/qubes-users/gFOct_ZZk1A/agAozg1lPAAJ

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXRhRyAAoJENtN07w5UDAw4nUP/1SOQIfShZ5rfYrMbWTXHk9J
nWOKCslV0ltXAd9zKBPAQCFfeth7sW0uFh70YTA669W8/ukTohElvVuvZJc1GAXU
ayDc8CJ8gA02JCgHrtkzlsRhUkNL6ND9ezEMHWYDl7WgI1T3T6Xf/QbiY6ncs2FY
a4j0lF5D+xz5usXtSDH4T88VIUjvwgx4aiJLUnwWjpjmM3sIAjJQC1Ef+xKv/4e0
GQTr6xHJWCY7DwvcWgk/EU88TXG5+uBiVRiAwZK8cS4o97KyAnpANUABwl0nO+KW
l5CoUKMPJ3jyuySIqAUd6S7gTren5zrX1XOr5c2tpjyRLFeZySS1zrnAdcMA/w7q
Z4kNxVK6CTruFc4k20J+wYEC/5E5RvXD4amdDK7QlAN7BX/zgOWVLmkHjBcyCMP+
7PNP8TVahaay7Sbyiy6Sfx50A6AF5Hay8Dq0xCoNr+0lFaLDAEkfd8fBLRIwhRKU
AuNvh1K1uZtfAy9BBFwKoQbSMFou12vgH6Kx8nHpvntsoJKS0m9OiwJhqsX6qIwj
qLNqPFsfDuw9jauaLdkyi8ySH5Igo09/WyYHV3eIooW2KN5liVzp8wHHlfiaulzF
K2W2U3F+OIQgUa+DojLkYWpDZUSrq+EY8ar6x0MVy4VRKrAEzyeWaIwPbgtFHn2J
XH7Dqkh1RDB9uetyybYM
=3Wkn
-----END PGP SIGNATURE-----

[Chris Laprise]

No, we don't have to trust a compromised vm in that way. The copy
operation itself is still safe.

> 2. Since the copied file may have been modified to be or replaced with
> a malicious file, opening it in the new, clean VM could result in
> cross-contamination.

Right. That's why copying and archiving files is fundamentally different
from opening them.

I think before long Qubes will get some additional 'sanitizing' tools...
for images and text files not just pdfs. That will make the prospect of
opening/examining files from untrusted sources far safer.

OTOH, if one wants to use a relatively trusted vm to quarantine and
catalog files from suspect sources, for example, the current Qubes tools
allow us to do that safely (i.e. operations are limited to copying and
storing). That's the reason why Qubes isolation in the same computer is
often considered safer than running multiple air-gapped computers... the
latter are not useful without data, so copying any data to them requires
using layers of complex drivers and formats (USB drive, optical disc,
etc.). In comparison, qvm-copy is ultra simple and very safe.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Are you sure about that? What prevents a compromised VM from feeding
different data to its qrexec-agent or modifying the target file before
it's copied to the destination VM?

>> 2. Since the copied file may have been modified to be or replaced
>> with a malicious file, opening it in the new, clean VM could
>> result in cross-contamination.
>
> Right. That's why copying and archiving files is fundamentally
> different from opening them.
>

Sure, but as a practical matter, what are the odds that boromirsbeard
(or anyone in the same position) just wants to copy the file out of
the compromised VM but not open it in the destination VM? Pretty low,
so I think point 2 is worth mentioning here.

> I think before long Qubes will get some additional 'sanitizing'
> tools... for images and text files not just pdfs. That will make
> the prospect of opening/examining files from untrusted sources far
> safer.
>
> OTOH, if one wants to use a relatively trusted vm to quarantine
> and catalog files from suspect sources, for example, the current
> Qubes tools allow us to do that safely (i.e. operations are limited
> to copying and storing). That's the reason why Qubes isolation in
> the same computer is often considered safer than running multiple
> air-gapped computers... the latter are not useful without data, so
> copying any data to them requires using layers of complex drivers
> and formats (USB drive, optical disc, etc.). In comparison,
> qvm-copy is ultra simple and very safe.
>
> Chris
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXR8mXAAoJENtN07w5UDAwNPgQAMdwOL8fCzm0dKzdvYQahgLH
FTaKPs+9VMXkbT/shZdMf+mlVieDRPptkFf1nYI+F109T/GDh9tcM78oLQVI8uNJ
kFi3DMELHiXA9StYlU+9AVbPPbz6pkdXdIw3O3eYCSlnSMv3rFl7RG7O9dKG4YA3
8IjawfVV9qih1MLW7WsWUcdm73NCP9lXSm7nko3o/2qqjVoTXmRoZuF2uf/6wVOT
2W/9XPT9POQ5h9O+aDPLmMG/xiuZkRE4ZeqiXvo6eNkmMN89sHWG5tlr0cISRZG7
kfIgWI2GRrlRe6jAvi4hVGkVxeNHCDSh7uad46UF01MfJrtHWDKj1wDwhoXuKXa+
egaStuo4aJ8Kmf9r2jeHvQNABqs4D9rn+Nc1BQGJ3B7OUDrKhjD1G/sbhE9BrvS0
Jg/afmbtjxb0mh1UvYKMZURxqhltrwsI8zmdtLfo0HsQGSwCTTUR1RfNY5ndmpxm
FVXIk3CqOJw1olbhi35lTQsS0QnqcUst3nIovZTtHEBotIKBJ2QOEuVUuns7DB+M
h72x8xGJnQBLRUmfT8QZ/w75IcIsUMp8K+Jj/YNTdIj+3XVBQkhOFASK5gM+0/Ot
yNBlF8IQspz1VvXiaBeU9EKbBNtLiE64wn8fyGz48Tno+o3QxeUfxOzDONTTobW1
82HjM+PGyJyNNGojHal7
=rw7o
-----END PGP SIGNATURE-----

[Chris Laprise]

Yes, I'm sure. But the safety of qvm-copy and your point about
modification are both true, and every Qubes user should realize it.

>
>>> 2. Since the copied file may have been modified to be or replaced
>>> with a malicious file, opening it in the new, clean VM could
>>> result in cross-contamination.
>> Right. That's why copying and archiving files is fundamentally
>> different from opening them.
>>
> Sure, but as a practical matter, what are the odds that boromirsbeard
> (or anyone in the same position) just wants to copy the file out of
> the compromised VM but not open it in the destination VM? Pretty low,
> so I think point 2 is worth mentioning here.

Yet, we still have to make the distinction. If we did not, there would
be no rhyme or reason to have confidence in more common operations like
"trusted pdf" or even system updates.

This is one of those subjects where there is a fine line to walk between
being too geared for a technical audience, and being too 'kind' to
novice users. If we say copy operations can cause compromise (to err on
the side of safety for a novice user), there are many MANY people who
are just experienced enough to "know" the logical conclusion that Qubes
can't protect them from anything and trusted pdf, secure dom0 menu
system and secure updates are therefore a "sham".

Trust me-- Hang out on Slashdot or Ars Technica forums sometime. You
will run into Qubes-haters who are very skilled hackers, yet they got
the wrong end of the stick. They hate Qubes or Xen because its
"fundamentally insecure" for technical reasons that don't exist.
Likewise, there are novices who may reject Qubes as they learn more
about computing and start to question how "unsafe copy" between any vms
can be consistent with good security.

So being mindful of the difference between copying and opening is
essential, as is reflecting that in the documentation and advice. To
heighten awareness of that difference is a positive thing for even the
most novice Qubes users.

FWIW, there is also another distinction here: Pasting info from an
untrusted vm into another vm does carry a significant risk. In that
respect it is not like copying.

Chris