On 10/13/2016 02:14 PM, Chris Laprise wrote: > > So this is dependent on OpenVPN's features, again.
Yes, I make no secret of the fact that my software depends on OpenVPN. I accept contributions to make it work with other VPN solutions. > > And is forcing your routing schema on an unknown VPN topology wise? I don't know what you mean by "forcing" or "my schema" or "wise". I know that my program creates a private routing table for the VPN, so the system routing table is not affected. This is less unsafe than, for example, what NetworkManager VPN does — which alters your system routing table. > > Routing tables should be irrelevant to whether non-VPN traffic is > blocked by a proxyVM. This is a nice opinion, and you are entitled to it. However, it turns out that using a blackhole routing rule is quite effective at blocking any and all non-VPN traffic. > A VPN server should be able to push down whichever routes it sees fit, > without any risk of leakage even if those rules are malicious... or > simply a configuration you can't anticipate. Oh, that's true. And Qubes-VPN supports that. Because it uses a separate routing table, the system's operation is not affected even if the VPN server sends malicious or nonsensical routes. > > Making the solution dependent on routing tables just makes the > security *and* the operation more precarious. While Qubes VPN does not depend solely on routing tables, I would like to see you prove these allegations. This allegation of yours sounds like something you can prove by reasoning or by example. Why not do it? Let's also get one thing out of the way here, because what you're saying here is borderline FUD. ALL VPN solutions depend upon routing tables. There are no VPNs that do not use routing tables on the client to direct traffic. Qubes VPN merely uses a *separate* routing table, not the system routing table (table #0). So when you say that "making the solution dependent on routing tables" is somehow bad, you're attacking *all* VPN software. > >> >>> * 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! > >>> * Hardly a model for 'fail closed': I forgot to mention that the software I wrote is 100% fail-closed. If the VPN fails, traffic from VMs will always be blackholed. There's no way that this rule can be altered by VMs or the VPN itself. >>> Instead of being steady-state, The steady fail-safe state is established very early on boot by the qubes-vpn-forwarding.service unit file. That steady fail-safe state — represented by the blackhole rule in table 78 and the firewall rule routing downstream traffic to table 78 — is never removed during any state transition. >>> blocking is dependent on state transitions in fw/routes (even worse, >>> ones that are initiated by OpenVPN events). Blocking should not >>> require active measures initiated by client software. >> Check the code again. Blocking happens way before VPN and Qubes >> Firewall starts. If there's a failure in the VPN, even if the >> re-blackholing fails, no traffic from the VMs will be routed, simply >> because everything is FWMARKed to go to routing table 78, which is dead >> by the time VPN fails. > > I can see the code where 'up' and 'down' are reconfiguring both > iptables and routing tables. You can see it, but you don't seem to have understood it. Maybe it is my fault for not documenting it, but I will fix that now. * The activation of qubes-iptables (right when the firewall is initially set up) triggers the activation of "qubes-vpn-forwarding on". This sets up the steady state (routing 100% blackholed). * OpenVPN "up" calls "qubes-vpn-forwarding setuprouting". This adds the routes that OpenVPN wants to table 78. Then, OpenVPN "up" directs the firewall to route AppVM DNS requests to the VPN DNS servers. Before "up", all AppVM packets, including DNS, get blackholed. After "up", they are NATted to the VPN. * OpenVPN "down" calls "qubes-vpn-forwarding blackhole". Blackhole simply removes all table 78 routes that aren't the blackhole route. This ends any routing on table 78, and therefore traffic from all AppVMs. It /is worth noting/ that, even if these routing rules were to not be deleted — they do, automatically, when the TUN/TAP device goes down — no routing would happen anyway. * "qubes-vpn-forwarding off" is never called except when qubes-iptables service is reloaded on the ProxyVM (not done unless you do it by hand). (BAM, just pushed the docs to the README file in the repo. https://github.com/Rudd-O/qubes-vpn#theory-of-operation ) > That is using OpenVPN events to shift between states,one of which is > the so-called "blackhole" mode... Does the word "blackhole" sound scary to you? It simply means "delete all routing rules of the VPN, leaving the already-existing null route in place". This is hardly a difficult concept to grasp or to insinuate negatively about. > which looks more like the makings for a zombie process. I don't know what you meant by this in this context. > > OTOH, its possible that Qubes proxyVMs might leak packets before Qubes > firewall starts, as you claim. That has implications for *most* use > cases involving proxyVMs. Did you think to test that and submit an issue? Only in VPN case. I wrote the fix for it :-). We're discussing it. > >> >>> * Specific to Fedora template and hard-coded for OpenVPN >> Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is >> the standard > ...is presumptuous. Yes, I am presuming that the people using the software I wrote will use OpenVPN. This is, of course, by no means the end of the story, of course. I will gladly add support for other VPN software, and perhaps even NetworkManager, to Qubes VPN. I just need to find users who are interested in getting those new features, and possibly help with them as well. Of course, once we have support for more than one VPN, it would be *great* if my software could be upstreamed. I'll work on getting there when time comes due. Not yet. > >>> * Not /rw based; Adds more services to template >> Partially true. Config goes in /rw as it should. Services are optional >> and need to be specifically enabled. > > They need to be enabled, but they are still there. That does > negatively affect security from the Qubes perspective; Are we doing a bit of security by superstition here? If the program is installed, but it never runs, because the user has not enabled the Qubes service or configured the program, how exactly is security "negatively affected"? Are the evil demons going to spawn from the evil program I wrote, just because it's present? Sorry, this sounds a bit too Poltergeist or Pet Semetery for me. > Why should we have even more privileged code laying around in multiple > VMs just because one of them uses a VPN? My program does not ship any privileged code. I repeat what I said earlier: installing my program does not run anything that affects VM state, unless the user has expressly enabled it. And even then, the changes to VM state are (a) volatile (b) minimal (c) non-interfering with normal ProxyVM operation. All of this is consistent with the Qubes OS system design principles. > > >> Frankly, much better than an instruction manual, or putting all of the >> stuff in /rw/config/firewall stuff, because it being a package, it can >> be updated regularly, given a repo containing the packages. > > Yes, you were suggesting that people incorporate your repo, Wut. I don't even /have/ a repo. Seriously, do you really dislike my work so much, that you need to find 100% fake reasons to smear it? > while pretending the Qubes-approved solution didn't exist. I never pretended there were no other solutions. Frankly, this sort of snap, baseless remark, it seems more like you have some sort of antipathy against me, or my program, for some reason. > > > Its the /only/ loop in that script ...and boy is it ugly. :) Give a line number please. I have that file open right here, and there is absolutely no busy loop in it. The only loop in the script has a nice "break" in it, and executes at most for two iterations (that is, of course, obvious, IF you understand the code!). > >> >>> * Marketing hyperbole like "leak-proof" should be replaced with terms >>> like "anti-leak" >> If you think it's possible to have this VPN leak, then prove you can >> cause a leak, and — if you succeed — I will plug the leak. > > Why move the goalposts? You explain why the existing solution, which > is very unlike your complex set of rules, Complex compared to what? 4 rules are not "complex", when you have more rules in the scripts of the official VPN documentation. > Lets "collaborate"? How disingenuous... OK then, you are also welcome not to collaborate with me. > > We already have a Qubes-approved solution that is considered secure. > You did not seek to package, improve, criticize or even /acknowledge/ > it before you started suggesting people integrate your repo into their > templates! That, quite frankly, is suspicious behavior reminiscent of > the "bum rush" and whether its inadvertent or not isn't my concern. > > If this seems uncouth to you, let me provide a reminder that this is a > project where Joanna has advised we should distrust even ITL staff. > Its advice that smartly sets the parameters of skepticism for just > this sort of occasion. There's healthy distrust, and then there's what you are doing, which is finding specious pretexts and faulty reasons to dislike something I wrote, which I made freely available. So, thank you for your feedback, but you have not given me anything I can use to make my program better or to help the users of my program. In the future, try to give feedback that is more consistent with those two goals. Or send a pull request — that talks way louder than insinuations and pretexts. -- Rudd-O http://rudd-o.com/ -- 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/2bdaee79-c037-e9cd-cc08-52e824927567%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
