Firewall restrictions through GUI don't affect ping

[emanruse]

Qubes OS release

4.1.x 4.2

Brief summary

Restricting the network connectivity of a qube through the Firewall tab in qube's GUI settings does not restrict ping - one can ping any host from the qube.

Restrict default ping to selected hosts if "Limit outgoing connections" is active. Make it user configurable through the GUI.

Steps to reproduce

1. For some qube, open Firewall rules tab in the Settings GUI
2. Click the "+" button to add a new rule
3. Set

Address = example.com Protocol = Any Port/Service - leave it as is (i.e. Any)

4. Start a terminal in the qube and run:

ping example.com
ping fsf.org

Expected behavior

Only ping to example.com should be possible. (because Protocol = any, Port/Service = any)

Actual behavior

It is possible to ping any host.

[UndeadDevel]

Take a look at the bottom of that Firewall Settings page, where it says that ICMP (ping) and DNS are not restricted and to use the command line tool (qvm-firewall) for more granular control.

[emanruse]

I know what it says and exactly because of that I am opening this issue. There is conflicting information:

• "any" protocol includes ICMP too (which, strictly speaking, is not just ping)
• all [...] ICMP (pings) will be allowed
• "Limit outgoing connections to..." means what it says

Should we also consider that it is actually more secure to apply the limitation, not to allow ICMP leaks?

[marmarek]

Should we also consider that it is actually more secure to apply the limitation, not to allow ICMP leaks?

https://www.qubes-os.org/doc/data-leaks/#the-role-of-the-firewall

[emanruse]

https://www.qubes-os.org/doc/data-leaks/#the-role-of-the-firewall

The current issue does not conflict that, as it does not propose to fool the user into thinking that perfect security is possible, but to make it easier to protect the VM from (at least) type 3 leaks (which are the most probable ones).

A UI warning and the docs can (and should) still inform the user about the other types without that resulting in deliberate non-restriction of connectivity.

The current issue also proposes to fix the current contradiction between "any" (claimed) and "any except ICMP" (actual).

[marmarek]

You missed the point. The firewall here is not to prevent leaks from a malicious VM. It's to prevent user mistakes like opening some random website in your banking qube.

[emanruse]

You link to a doc that says:

"[...] Qubes firewall [...] can fully protect against leaks of type 3."

To that I answer:

The current issue does not conflict that, as it does not propose to fool the user into thinking that perfect security is possible, but to make it easier to protect the VM from (at least) type 3 leaks (which are the most probable ones).

After which you say:

You missed the point.

I am baffled.

The firewall here is not to prevent leaks from a malicious VM. It's to prevent user mistakes like opening some random website in your banking qube.

That is simply not true, forgive me. A firewall is not a usability tool for preventing user mistakes. What you describe is just an effect of having it, not its definition or design goal.

In any case, deliberate non-restriction of connections over a particular protocol works both against what the doc says, and the specific example you provide. Unless anyone can actually demonstrate why unrestricted ICMP (against user choice to restrict "any" protocol) is better for security, it seems to me the current issue is quite valid and resolving it would have practical security benefits.

[3hhh]

I agree that the firewall GUI should make all options available on command-line to the user and not have that weird "DNS & ICMP allow" hidden default. To preserve backwards compatibility it'd probably be best to keep it, but make it visible to and configurable by the user via the GUI.