On 10/13/2016 01:08 AM, Manuel Amador (Rudd-O) wrote:
On 10/13/2016 03:13 AM, Chris Laprise wrote:
Here is a rundown of initial concerns...
* Routing tables should not be manipulated when VPN clients will
surely do this as well
The program prohibits OpenVPN from manipulating routing tables.
So this is dependent on OpenVPN's features, again.
And is forcing your routing schema on an unknown VPN topology wise?
* Unknown side-effects with different VPN topologies (i.e. atypical
routing commands pushed down to the VPN client)
Almost no routing instructions are obeyed. Those which are obeyed, are
applied to routing table 78, which prevents malicious server
manipulation of ProxyVM routing tables.
Routing tables should be irrelevant to whether non-VPN traffic is
blocked by a proxyVM. 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.
Making the solution dependent on routing tables just makes the security
*and* the operation more precarious.
* 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.
* Hardly a model for 'fail closed': Instead of being steady-state,
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. That is using OpenVPN events to shift between
states, one of which is the so-called "blackhole" mode... which looks
more like the makings for a zombie process.
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?
* 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.
* 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; Why should we have even more
privileged code laying around in multiple VMs just because one of them
uses a VPN?
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, while
pretending the Qubes-approved solution didn't exist.
* Not tested with Whonix/Tor
True. Then again, Whonix has its own "VPN" solution called TOR.
Oh, OK.
* Uncommented code
There are a few comments now. Surely not enough to satisfy your
standards, but I welcome pull requests.
* A full throttle busy-wait loop in 'qubes-vpn-forwarding.in'
Please point out the line of code where that happens. I don't think I
have done that.
Its the /only/ loop in that script ...and boy is it ugly. :)
* 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, is insufficient *other* than not
being packaged.
* Critique of existing solution stops at 'No packaging'[1]; Oddly,
nothing pertaining to anti-leak abili
Sorry, gotta go to bed. I have a suggestion: I think we will
collaborate better w.r.t bringing a standardized leak-proof solution to
Qubes, if we approach the issue in a non-confrontational and
collaborative way. I'm happy to have criticisms because they tend to
improve the software, but I fail to see valid criticisms here, which
makes me feel like you jumped to critiquing without trying what you were
critiquing. Let's get some more solid criticisms based on facts and not
on opinions or hunches.
Lets "collaborate"? How disingenuous...
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.
Chris
--
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/9c30b505-d36c-1238-fb0b-df377a9c808e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
