Confused about Update Proxy

[sur...@vfemail.net]

First, would just like to thank all of you for wonderful work.
Installation was effortless. Interface is beautiful and highly
usable/integrated.

After having read the FAQ and User Docs (including
https://www.qubes-os.org/doc/SoftwareUpdateVM/), I'm still very
confused about how the Update Proxy works. If my understanding is
correct, it is designed to reroute requests to repositories and
redirect them to 10.137.255.254:8082. A proxy server on the net path
picks this up and makes the request to the repository?

If I'm not confused enough, the setting to "Allow connections to
Updates Proxy" appears on the Firewall rules page, which is only
available to AppVMs. Since updating occurs in Templates, would this
option only be applicable to Standalone VMs?

Access to Updates Proxy is enabled by default on Template VMs. Since
it is best practice not to connect a NetVM to a Template, does this
mean the Updates Proxy will by handled by the NetVM and transmit over
Clearnet? What if I want all updates to be routed over TorVM? Is that
what the UpdateVM setting is for in Global Settings? And can any VM be
an UpdateVM? Why would anyone choose an AppVM to be the UpdateVM?

I don't even need to emphasize how unsettling it is to have network
traffic from a VM that has NO NET VM!!! An anonymity distribution
should always provide ample warning when anything is passed in the
Clear...

Speaking of warnings, I set Firewall Rules in an AppVM and later
discovered that they had been reset?!?! In what situations can that
happen? Whatever is triggering that should definitely be accompanied
by a confirmation dialog. People depend on firewall/routing rules for
safety. They should never be changed without warning. Thanks for
replies.


-------------------------------------------------

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!

[Unman]

It seems to me that you have a good understanding of the proxy process.
Your description in the first paragraph is correct.

On the other points:
You can, if you wish, allow ANY VM to use an update proxy, just as you
CAN update any VM, (even template based AppVM). If you update a template
based VM then the updating will be lost on reboot.

On a default install, (R3rc2 e.g), the Update proxy is sys-firewall, and
the templates have that as their NetVM. (qvm-ls will show you the NetVM
associated with the templates, or you can enable this view in the GUI
manager.) So there is no network traffic from a VM without a NetVM.
It follows that the templates and dom0 will update on clearnet by default.
As qubes doesn't claim to be an anonymity distribution this isn't
surprising.

You can have ANY ProxyVM working as an update proxy.
If you want updates running over tor, then set up a VM to act as proxy
with torVM as its NetVM, and put your templates with that VM as the
NetVM.
ie TemplateVM - proxyVM - torVM - sysnet

You could also put a caching proxy inline below the proxyVM if you have
many templates and want to cut down on network traffic.

Marek has pointed out that the "UpdateVM" setting in the GUI manager is
used to set the UpdateVM for dom0 only. So you can have one setting
there and another for individual VMs. If you set this to the same
proxyVM behind the torvm then ALL updates will run through the tor
network.

Finally, you don't say how you set Firewall rules in an appVM - if you
set them in the GUI or at dom0 command line then this is clearly a bug you
should report at qubes-issues.
On the other hand if you set them with iptables in the VM remember that
any system changes will be lost on reboot. For lasting firewall rules
in the VM record them in /rw/config/qubes-firewall-user-script, or save
them in /rw/config and restore them with iptables-restore.
Alternatively you could set firewall rules in a template which will then
be inherited by every appVM based on that template.

unman

[sur...@vfemail.net]

Thanks for your clear and detailed answer. I'd like to confirm a few points.

1. No VM is able to access outside network (through sys-net or
otherwise) unless it has a NetVM defined explicitly. The Update Proxy
allows you to connect ANY Net or Proxy VM to ANY
(App,Template,Standalone) VM and give it access to ONLY the
repositories. The important point is that using the 'Allow connections
to update proxy' option, allows you to also enable 'Deny network
access...' for all other traffic. (If this is true, then my
TemplateVMs must have obtained updates in the background BEFORE I
disconnected their NetVMs - source of my confusion. Also, the 'Updates
pending!' icon seems to be bugged...)

> You can have ANY ProxyVM working as an update proxy.
> If you want updates running over tor, then set up a VM to act as proxy
> with torVM as its NetVM, and put your templates with that VM as the
> NetVM.
> ie TemplateVM - proxyVM - torVM - sysnet

2. Do all ProxyVMs have the Update Proxy service enabled by default?
(Guess that would be qubes-yum-proxy). Also, yum-proxy-setup is
enabled automatically in client VM's when the 'Allow connections to
update proxy' option is enabled?

> Finally, you don't say how you set Firewall rules in an appVM - if you
> set them in the GUI or at dom0 command line then this is clearly a bug
you
> should report at qubes-issues.
>

> unman


Pretty certain that this resolved my issue: qvm-firewall error after
renaming vm
(https://groups.google.com/forum/?hl=en#!topic/qubes-users/BL3Caxd6ejk)

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Aug 04, 2015 at 06:45:37PM -0500, sur...@vfemail.net wrote:
>
> Thanks for your clear and detailed answer. I'd like to confirm a few points.
>
> 1. No VM is able to access outside network (through sys-net or otherwise)
> unless it has a NetVM defined explicitly.

Yes.

> The Update Proxy allows you to
> connect ANY Net or Proxy VM to ANY (App,Template,Standalone) VM and give it
> access to ONLY the repositories.

Not sure what you've meant here. The 'Allow connections to update proxy'
means:
IF the VM (template VM, standalone VM, anything) is connected
(directly or indirectly) to a VM providing an "updates proxy" service,
THEN the service can be used to access updates repositories, only.
Even when default policy for that VM is to block all the traffic.

But if such VM isn't connected to any VM providing such service (for
example not connected to any netvm at all), updates proxy will not be
available, even if 'Allow connections to update proxy' is enabled.
We may change that in the (far) future [1]. If that happens, there will
be clear indication of that.

[1] https://github.com/QubesOS/qubes-issues/issues/806

> The important point is that using the
> 'Allow connections to update proxy' option, allows you to also enable 'Deny
> network access...' for all other traffic.

Exactly.

> (If this is true, then my
> TemplateVMs must have obtained updates in the background BEFORE I
> disconnected their NetVMs - source of my confusion. Also, the 'Updates
> pending!' icon seems to be bugged...)
>
>
> >You can have ANY ProxyVM working as an update proxy.
> >If you want updates running over tor, then set up a VM to act as proxy
> >with torVM as its NetVM, and put your templates with that VM as the
> >NetVM.
> >ie TemplateVM - proxyVM - torVM - sysnet
>
>
> 2. Do all ProxyVMs have the Update Proxy service enabled by default? (Guess
> that would be qubes-yum-proxy).

Not ProxyVMs, NetVMs. Yes, all of them have Updates Proxy service
enabled by default. 'qubes-yum-proxy' is an deprecated name, current one
is 'qubes-updates-proxy'.

> Also, yum-proxy-setup is enabled
> automatically in client VM's when the 'Allow connections to update proxy'
> option is enabled?

Yes, exactly. The 'yum-proxy-setup' (actually 'updates-proxy-setup')
option is responsible for setting yum/apt to actually use the updates
proxy.

> >Finally, you don't say how you set Firewall rules in an appVM - if you
> >set them in the GUI or at dom0 command line then this is clearly a bug
> you
> >should report at qubes-issues.
> >
> >unman
>
>
> Pretty certain that this resolved my issue: qvm-firewall error after
> renaming vm
> (https://groups.google.com/forum/?hl=en#!topic/qubes-users/BL3Caxd6ejk)

BTW qubes-core-dom0-3.0.18 is already uploaded to testing repository.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVwowQAAoJENuP0xzK19csIl4H/RsBq4KMFohXeUAlKlS7UvLh
mDueS6CVWuwqcfyAp/7qbwIlOSSRiCk4jyEBfUft2Z1MixkosR4Ule+ulSbfwop2
56+CmSSEsgXz9PIG9lgqFsP6y2EzXl3ZBtgsUh1rE+VJfQzhkDaJ2h1gRtUZXB/x
pyBk0yIeRBk6DzWLgSyTp4GjXlcl0vTrvbYSsc/MlI23QXHMiIr7Wy2Jty166cO/
wZJpvBNW0Jw0eexB+hAo9yCBhz7bn9+knyiW5qQVO7kCHNAXPwY/WT78ojd8WdpD
smcrVYY/Sd7FcC7VjPhTLuCDJWcW8+yi51VsViYHQOvG+SP0UiaIlVpD2kQLU7c=
=T/gW
-----END PGP SIGNATURE-----

[sur...@vfemail.net]

Thanks for explanation. Almost got it :) Would like to wrap-up with an
example.

On 2015-08-05 17:20, Marek Marczykowski-Górecki wrote:
>
> IF the VM (template VM, standalone VM, anything) is connected
> (directly or indirectly) to a VM providing an "updates proxy" service,
> THEN the service can be used to access updates repositories, only.
> Even when default policy for that VM is to block all the traffic.
>

my emphasis on INDIRECTLY.

>> 2. Do all ProxyVMs have the Update Proxy service enabled by default?
>> (Guess
>> that would be qubes-yum-proxy).
>
> Not ProxyVMs, NetVMs. Yes, all of them have Updates Proxy service
> enabled by default. 'qubes-yum-proxy' is an deprecated name, current
> one
> is 'qubes-updates-proxy'.
>
>> Also, yum-proxy-setup is enabled
>> automatically in client VM's when the 'Allow connections to update
>> proxy'
>> option is enabled?
>
> Yes, exactly. The 'yum-proxy-setup' (actually 'updates-proxy-setup')
> option is responsible for setting yum/apt to actually use the updates
> proxy.
>

EXAMPLE:

AppVM -- TorVM -- NetVM -- Internet

AppVM is set to Deny all traffic... AND to Allow connections to Updates
Proxy. (updates-proxy-setup is now enabled on AppVM)

connected to TorVM with the goal of sending all traffic over Tor.

TorVM is a proxyVM and hence does not have qubes-updates-proxy enabled
by default.

NetVM has qubes-updates-proxy enabled by default.

The Firewall Rules to Enable (or Disable) traffic will route (or block)
all traffic over Tor (except for repository updates).

Regardless of the Firewall Rules to Enable or Disable traffic, all
repository update requests will be captured by the NetVM and routed over
Clearnet.

To ensure updates are routed over Tor requires manually enabling the
qubes-updates-proxy service on the TorVM. (Assuming that the proximity
of TorVM to AppVM gives it precedence over NetVM???)

If this is all true, should it not be a concern that AppVM can "see"
beyond its immediate connection? ie that traffic can BYPASS a node in
the chain?

Thanks.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Actually TorVM is somehow special case here - it doesn't support
standard Qubes firewall settings - so the whole firewall tab will be
ignored for VMs (directly) connected to TorVM.

Also TorVM will capture (and route over tor) all the traffic, including
traffic directed to updates proxy. This means that updates proxy running
in NetVM will not be available for an AppVM - if you try to use it, the
connection would fail. At least it will not download updates over
clearnet...

> To ensure updates are routed over Tor requires manually enabling the
> qubes-updates-proxy service on the TorVM. (Assuming that the proximity of
> TorVM to AppVM gives it precedence over NetVM???)

Theoretically you're correct. In practice it would not be enough,
because traffic originated from the TorVM itself isn't routed through
tor (as noted in documentation[1]). So if you want to route all the
updates through tor, you have two options:
1. insert another ProxyVM before TorVM and enable qubes-updates-proxy
there.
2. disable usage of qubes-update-proxy

Actually there is also third option:
3. Use Whonix gateway[2] instead of TorVM. It has updates proxy integrated
and routes all the updates over tor.


[1] https://www.qubes-os.org/doc/UserDoc/TorVM/
[2] https://www.qubes-os.org/doc/Templates/Whonix/

> If this is all true, should it not be a concern that AppVM can "see" beyond
> its immediate connection? ie that traffic can BYPASS a node in the chain?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVwrG2AAoJENuP0xzK19csL+cH/0VMpGIJTuZl/GBSjVxh6iw+
iSi0qdM5hTBc72tvY16XdfB/S5zSvqymDlUIVF0ikTT3oeuAAuPYlmi0mtJcFeRm
hKtQQ24pU/gRC4ZRgJfYr3sAx3tekOTMO2JPaihehx3H2c0SCkykwQC8MpPO3NYM
K8CtGRaLXi6HOmlpWKBe66WQmoOzny0qIP35ReHMp6Fg0EMI+Q7MAZ1Eop78jZA7
bRViSsglqG8Dvhe8nQ6Ohp99UfqWGziqmX1OBF5NdXbkkO1O/Xwo0D20gPXAaQfF
p7/TiS5ADxhTt6RK2SY7PU6Qw+hLVt2YpovVtjIgYuvlB8OXrWFEV5J6cdRZP/8=
=D4iU
-----END PGP SIGNATURE-----