On Thu, Feb 14, 2019 at 03:13:50PM +0100, ashleybrown...@tutanota.com wrote: > Hopefully one day they revert it back to how it was in 3.2. A very common > use-case for the firewall is likely to ensure things like DNS requests do not > happen through the normal means (and instead go over something like Tor or a > VPN). Unfortunately, the current config does not make it very obvious that > someone should block DNS ports. Making it very easy for someone to shoot > themselves in the foot because the interface is not intuitive (it says it > blocks all traffic other than what is specified and then later modifies this > saying "just kidding, we let DNS through") > > Feb 14, 2019, 11:59 AM by simon.new...@gmail.com: > > > On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon....@gmail.com > > wrote: > > > >> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com > >> > <mailto:simon.new...@gmail.com>>> wrote: > >> > > In 3, if i clicked on "block connections" in the Qubes manager > >> > > firewall section, there was (if memory serves me) an option to block > >> > > DNS and ICMP. > >> > > > >> > > That is not present in R4 (though docs say you can disable DNS and > >> > > ICMP manually) > >> > > > >> > > I'm just wondering what the logic behind the removal was? I would have > >> > > thought that a general user who clicks "block connections" on Qube > >> > > would not expect the qube to be able to actually send out and receive > >> > > network packets such as DNS or ICMP. This presents information leakage > >> > > scenarios (default DNS lookups of given qube) and also potential > >> > > egress vectors if a qube is ever compromised (DNS tunnelling, ICMP > >> > > tunnelling). > >> > > >> As I said, I understand the documentation is correct. thats not my > >> question. My question is why was it removed as an option when the firewall > >> box itself in network manager says "Deny network access except..." > >> > >> My point is it is counter intuitive. If it says "deny network access > >> exccept..." then there is an expectation that it will deny network access > >> except for what is specified. There used to be tick buttons (allow > >> updates/allow ICMP/allow DNS), which made it clear on the granular control > >> there - but were removed in R4. The underlying subsytems you can still do > >> that, sure. > >> > >> Can I suggest that the wording "deny network access except..." is changed > >> to "Deny TCP and UDP access except ..." for the avoidance of any doubt. > >> > > > > > > https://github.com/QubesOS/qubes-manager/pull/153 > > <https://github.com/QubesOS/qubes-manager/pull/153> > >
Please dont top post - it breaks the thread of the conversation. I dont find the current position confusing, since the DNS and ICMP position is clearly stated in the NOTE at the bottom of the window. Simon, to answer your original question, there are many features in 4.0 which are aimed at simplifying use of Qubes. I think this is one of them. The underlying issue is this: if you want to set a firewall rule using a named site, then you must not only set the rule, (and the resolution will be set at the upstream firewall), but you must also enable DNS - otherwise your qube will not be able to resolve the address, even though you have correctly set the firewall rule. This adds a layer of complexity which a naive user would not understand. The decision was made to keep DNS open in a trade off between usability and security. There's also an underlying assumption that users who want more will be able to negotiate command line tools. This assumption may be misplaced. There are many users (not only of Qubes) who consider themselves "power users" (never understood what that meant), but dont seem able to understand iptables or use anything except a GUI. (Just to be clear, I'm not aiming at any contributor here.) As for ICMP, it's a moot point whether you should ever block ICMP at firewall level. Again, the benefit of having ICMP enabled is that basic network mechanisms are enabled, and basic diagnostic tools are available. It's a trade off between security and usability. As with *all* parts of Qubes, if you dont like the defaults change them on your system. If you like, propose a change by submitting a PR. There's an open issue on exactly this, where Marta outlined the issue and invited contributions that would allow the change and also keep clarity for naive users (my gloss). No one has yet stepped up. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190214153524.ofdhx3snbfjiijmu%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
