Rework qubes-netwatcher service

[marmarek]

Background: this service is meant to run in ProxyVM, watch for external IP
change and reload firewall on such event (to force names to be resolved again).
This is because some services (especially big ones) use DNS-based load
distribution and serves different IP(s) based on client location.

Currently this is broken, because it uses xenstore to watch entry in another
VM's tree (if have permission for that). In R3 we use QubesDB instead of
xenstore and it isn't possible to access other VMs data. Instead we should add
some qrexec service(s) which will reload firewall and call it whenever such
event is discovered by NetVM.

Yet to be defined who should call this service. Currently I see two options:

1. NetVM itself - should call in every VM connected to it. This means NetVM
   will need know names of connected VMs. Also every VM would know name of its
   NetVM.
2. Dom0 in response to event (some other service call?) from NetVM.

Since the first option would disclose potentially sensitive information,
especially when using AnonVMs, the second option would be better. The question
is which VMs should be informed:

• only directly connected ProxyVMs?
• all ProxyVMs down in the chain
• all VMs down in the chain

This isn't trivial choice because some ProxyVMs may be for example VPN VMs or
Tor VMs, which does not need such information and giving it there may be
potentially harmful (correlation attacks against anonymity).

Or maybe we should simply remove this mechanism? And recommend using IP
addresses instead of names in firewall rules (which is good idea anyway). This
would mean that setting rules like "allow: google.com" would no longer be
(easily) possible.

[adrelanos]

Did some user report yet, this feature being broken?

I guess adding rules manually such as "allow: google.com" is something only the geeks use anyway? So for simplicity the whole feature could be removed.

[adrelanos]

Did some user report yet, this feature being broken?

I guess adding rules manually such as "allow: google.com" is something only the geeks use anyway? So for simplicity the whole feature could be removed.

[marmarek]

On Fri, Sep 25, 2015 at 11:56:09AM -0700, Patrick Schleizer wrote:

Did some user report yet, this feature being broken?

Not yet, but we haven't released final 3.0 yet ;)

I guess adding rules manually such as "allow: google.com" is something only the geeks use anyway? So for simplicity the whole feature could be removed.

Maybe for google.com, yes. But imagine EmailVM for accessing gmail over
imap for example.

Anyway if no user would complain about that in R3.0, IMHO we can remove
this.

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?

[marmarek]

On Fri, Sep 25, 2015 at 11:56:09AM -0700, Patrick Schleizer wrote:

Did some user report yet, this feature being broken?

Not yet, but we haven't released final 3.0 yet ;)

I guess adding rules manually such as "allow: google.com" is something only the geeks use anyway? So for simplicity the whole feature could be removed.

Maybe for google.com, yes. But imagine EmailVM for accessing gmail over
imap for example.

Anyway if no user would complain about that in R3.0, IMHO we can remove
this.

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?

[qubesuser]

If I'm not misunderstanding, this doesn't seem to be very reliable, because an host could use a low DNS TTL and change its DNS response frequently, and then the firewall wouldn't work properly because the IP address in later responses wouldn't be allowed.

The only reliable way seems to be configuring a DNS proxy to add an iptables rule whenever it returns an A or AAAA record for a domain in the firewall rules.

It seems that dnsmasq provides that functionality using the --ipset option.

There also needs to be ad-hoc handling for applications connecting to Tor SOCKS ports since those never send DNS requests or IP packets with the target address. There doesn't seem to be any way to tell Tor to only allow outbound traffic to certain hosts, so unless I missed it it seems this would require writing a custom Tor controller that applies the firewall policy.

[qubesuser]

If I'm not misunderstanding, this doesn't seem to be very reliable, because an host could use a low DNS TTL and change its DNS response frequently, and then the firewall wouldn't work properly because the IP address in later responses wouldn't be allowed.

The only reliable way seems to be configuring a DNS proxy to add an iptables rule whenever it returns an A or AAAA record for a domain in the firewall rules.

It seems that dnsmasq provides that functionality using the --ipset option.

There also needs to be ad-hoc handling for applications connecting to Tor SOCKS ports since those never send DNS requests or IP packets with the target address. There doesn't seem to be any way to tell Tor to only allow outbound traffic to certain hosts, so unless I missed it it seems this would require writing a custom Tor controller that applies the firewall policy.

[marmarek]

The question is whether we need this feature at all. I'd leave the
current (broken) state for now and think about implementation when
really needed by users.

R2 have no solution for low DNS TTL load distribution and no one complained.

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?

[marmarek]

The question is whether we need this feature at all. I'd leave the
current (broken) state for now and think about implementation when
really needed by users.

R2 have no solution for low DNS TTL load distribution and no one complained.

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?

[marmarek]

I think the task here is reduced to: clean up leftovers of qubes-netwatcher service.
Then, if any other mechanism is needed, implement it in new firewall API discussed here:
https://groups.google.com/d/msgid/qubes-devel/20160114163808.GW4892%40mail-itl

[marmarek]

I think the task here is reduced to: clean up leftovers of qubes-netwatcher service.
Then, if any other mechanism is needed, implement it in new firewall API discussed here:
https://groups.google.com/d/msgid/qubes-devel/20160114163808.GW4892%40mail-itl

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.29-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.29-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.29-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.29-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.30-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.30-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.30-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.30-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update