On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote:
* Interdependent packet marking, detection and routing rules are
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
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
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 |
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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.