warn the user if qubes-firewall settings are ignored

[john-david-r-smith]

Qubes OS version

R3.1

---

Setting:

VM A has some qubes-firewall settings.
A's netvm does not support qubes-firewall settings.

Expected behavior:

Display a warning to the user when the netvm is set / fw options are added.
Maybe disconnect the netvm until the fw-rules are deleted / a netvm supporting qubes-fw settings is set.

Actual behavior:

The settings are dropped silently.

---

Related:

https://groups.google.com/forum/#!topic/qubes-users/FCJVUF07E2s

[marmarek]

There is such message already:

But it is visible only when switching to firewall tab, not when opening it directly from the toolbar...

[andrewdavidwong]

CCing @bnvk so that this can be taken into account in the Qubes Manager rework (#1870).

[john-david-r-smith]

i don't get this message.
maybe i did once and it only appears once? (this would be a bug in my opinion)
maybe you are using some dev-build?
my system is R3.1, up to date (just checked again.) and i can't remember changing anything that would have disabled such a message.

what i did:

1. create a new vm with some whonix-gw "tor" as netvm
   => network: my-new-vm -> tor -> sys-firewall -> sys-net
2. set fw rules to deny networking + forbid ICMP + DNS => (no message)
3. tested network:

[user@my-new-vm ~]$ curl torproject.com

and got the html code.
4) connected my-new-vm to sys-firewall
=> network: my-new-vm -> sys-firewall -> sys-net
5) tested network again.

[user@my-new-vm ~]$ curl torproject.com
curl: (6) Could not resolve host: torproject.com

6. set tor as netvm (no message)
   => network: my-new-vm -> tor -> sys-firewall -> sys-net

what i would expect to happen:
action 2) : display the warning you posted
action 6) : display a warning and set none as netvm.
i would set none to protect against user errors:
a) the user may have clicked the warning away.
b) the user may wanted to fix this later and forgot.
if either the old or new netvm is used there could be leaks.
in case of:

• new netvm: the fw rules are ignored
• old netvm: the user probably had a reason to change the netvm (e.g. from sys-firewall to tor)
  now there may be leaks of the user's ip.

[andrewdavidwong]

This is actually a duplicate of #1815, then. The real issue you're describing is that Whonix-Gateway does not currently support firewall rules. This is a known issue, which I brought up here and here, which branched off here and is being tracked in #1815 and here.

Short answer: For now, there's no way to enforce firewall rules for a VM using a whonix-gw as its NetVM, but a solution is in the works.

[john-david-r-smith]

but this was not about whonix not being able to apply the rules or enforcing these rules.
it was about the system warning the user if something like this happens (not only in combination with a whonix-gw, but with any netvm silently ignoring these settings)

[andrewdavidwong]

Are there any other situations besides Whonix in which firewall rules are not enforced? If not, then wouldn't fixing that also fix this? The end result would be the same: there is never a failure to warn the user that firewall rules have not been enforced (because they're always enforced).

In other words: Isn't the proper solution (and therefore the proper issue to be filed) to make sure that firewall rules are always enforced, rather than trying to come up with a system that warns the user whenever they're not (which should never happen)?

Now, you might say, "Well, it should never happen. But what if it does?" I can see the value of having a warning system for cases like that, but by the same logic, it would be great to have a warning system for everything that could go wrong in Qubes. I'm just not sure it's practical to build all those warning systems.

[john-david-r-smith]

you are right. currently i don't know any other cases where this happens.
but wont there be the same questions if in future something like this happens again (maybe there is a new proxyvm with missing support)?
if you tell the user what is wrong instead of failing silently it causes less confusion.
i think it would be good to have a warning if the implementation does not take to much code.
(i think it should not be that hard to implement, if the code triggering the warning from marmarek's post does work in this case)

furthermore i think qubes, as an security oriented os, should warn the user if some leaks could occur because of some component not working as expected. (as long as it can detect this)

[andrewdavidwong]

Ok, I'll reopen this.

[andrewdavidwong]

On 2016-09-20 10:16, mittendorf@[...] wrote:

Hey,

Firewall rules are set for a specific VM/Qube. From common understanding people would probably think that those rules are active no matter what happens outside of that very VM/Qube, but in fact it seems like those rules are active if and only if there is an ProxyVM connected to that VM/Qube.

Examples:

1. I can configure firewall rules for a ProxyVM, but they are not actived, if that ProxyVM is connected to a NetVM (if I connect another ProxyVM in between, this might probably work?!)

2. I can configure firewall rules for a AppVM, which will not be active if that VM is connected

And: What happens if a ProxyVM does not implement the firewall service, or if the firewall service crashes in the ProxyVM ?
I cannot find more information about the firewall mechanism than "centrally managed in Dom0 and exposed to each Proxy VM through Xen store" from http://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html

Ideas:
a) A warning if an AppVM is (about to be) connected to a NetVM (instead of a ProxyVM).

b) Do not allow "firewall rules" being set for ProxyVMs (I think Proxy-Chains are rather unlikely being used?!)

c) A warning about DNS-Names in firewall rules

[c) A warning if a connected ProxyVM does not activate the firewall rules]

thank you,

Robert Mittendorf

[tasket]

In current 3.2RC I do not get any warning when switching a proxyvm from another proxyvm to a netvm. The configured firewall rules simply cease to work.

There should be a warning, and the firewall settings tab deactivated.

[ubestemt]

@andrewdavidwong If you (or someone else) point me to the relevant code for the warning message (when opening the Firewall tab with sys-net as NetVM) I'll see if I'm able to implement it for sys-whonix too.

[andrewdavidwong]

If you (or someone else) point me to the relevant code for the warning message (when opening the Firewall tab with sys-net as NetVM) I'll see if I'm able to implement it for sys-whonix too.

@marmarek?

[marmarek]

It's here: https://github.com/QubesOS/qubes-manager/blob/master/qubesmanager/settings.py#L192-L201
The problem is that, currently there is no information whether given ProxyVM really support firewall enforcing. You can guess bases on its name (sys-whonix), but if one rename this VM, it would not work anymore. But maybe indeed providing some warning at least in default configuration is better than no warning at all.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.1-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.6-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 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 python2-dnf-plugins-qubes-hooks-4.0.6-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 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.6-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, 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.6-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch 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, 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-dom0-4.0.4-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update