On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote:
* Interdependent packet marking, detection and routing rules are
needlessly complex
FWMARK was the only way to get blackholing to work reliably without
interference from the Qubes OS firewalling system.
So you added complexity where simply blocking all forwarding to/from
eth0 would have sufficed.
Not really.  I implemented the simplest and least-invasive solution I
could think of.  It's four directives:

1. Instruct the routing engine to route all packets from downstream VMs
to use table 78.  This happens very early during boot, right after the
Qubes OS default firewall rules are loaded, and so it happens that VMs
cannot leak.
2. Tell table 78 to route all traffic to the VPN if the VPN interface is
active, and to blackhole all traffic if the VPN interface goes down.
This is actually quite cool, because there's no need to clean up
anything if the VPN fails — the routes disappear when the TUN/TAP device
goes away, leaving the blackhole route active.
3. Add two firewall rules directing all DNS requests from downstream VMs
to the DNS servers of the VPN.

I think, in my humble opinion, that this compares /quite favorably/ with
(the doc) asking the user to write several scripts, all of which make
much more invasive iptables modifications, while still allowing the VPN
server to muck with the system routing table, a practice which under
some circumstances could cause the ProxyVM itself to use the wrong DNS
servers, or to fail to reconnect to the VPN.

Additionally, I see that some of the tables that the doc's scripts
modify are actually tables that the Qubes firewall may revert to their
original state, so it's quite easy for a firewall config change to blow
those rules up, leaving the user with a leaky VPN.  Granted, the
firewall config change will only last about a half a second, because the
user firewall script will be invoked afterwards, but during that
half-second, traffic can leak via the eth0 route.  OOPS!

Now that is something interesting. So the Qubes firewall is supposedly bad. And we can let most users suffer whatever consequences when they block traffic with sys-firewall, because only our specific VPN application matters??

Keeping in mind that the default policy of FORWARD is DROP, we should also consider whether a stream of iptables commands is too slow to be secure. And if so, ask why 1) the user firewall rules are in script format; Or why 2) the commands aren't all combined for an iptables-restore; Or why 3) the chains aren't started with a temporary REJECT while they are being populated. ANY. ONE. Of these will address the issue for VPNs and all the other use cases.


Here is bog-standard advice for properly handling firewall rules in Fedora:


Or how about:
$ cat internal-qubes-rules qubes-user-rules iptables-commit-cmd | iptables-restore

At this point, we all need to know if Qubes firewall will be fixed in a timely fashion. I am wondering what the heck "reasonably secure OS" is supposed to mean in this context.


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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to