On 05/27/2016 09:41 AM, Ivan wrote:
Hi,
On 05/27/2016 04:00 PM, Chris Laprise wrote:
Some notes about a VPN firewall solution...
Objectives:
* Prevent all communication between downstream vms and upstream clearnet
(eth0) when the vpn client fails or the link goes down.
* Implement vpn link as a dedicated vm, transparent to downstream vms.
* Remain compatible with conventional server names for the vpn server.
* Prevent accidental communication from non-vpn programs in vpn vm to
anywhere.
* Prevent attempted communication with non-vpn programs in the vpn vm
(appears already enforced by Qubes firewall).
Roles:
* The vpn vm is generally trusted. It is assumed its programs won't try
to impersonate openvpn (send data via port 1194), for example.
If that's a concern, you may restrict sending data to port 1194 only
by the openvpn user, like so:
-A OUTPUT -p [...] -o eth0 --dport 1194 -m owner --uid-owner openvpn
-j ACCEPT
The same can be done for the owner of programs doing domain name
resolution.
This is of course fine if the reason a program would "impersonate"
openvpn is because of a developer's mistake or a weird setup. If those
programs are malicious those rules won't help much (privilege
escalation, and game over for that vm).
Cheers,
Ivan
I surmise that a weird setup or mistake could as easily run other
programs as the openvpn user (and for many network functions, the error
is far less detectable). The difference is that various distros may or
may not set this up as default, making this aspect of setup for Qubes
difficult to script and document. Scripting from within openvpn is also
harder with the user sandbox in place, and it gets us no added security
(the vpn password/key is the only thing of value in the vm).
In this Qubes context, the port number identifies the program about as
accurately as a username, and its infinitely simpler and more likely to
work. That's important, since trying to protect against occasional
mistyped commands in the vpn vm is not the point of all this... IMHO its
a tertiary concern. The main issue is that no data be forwarded between
vif+ and eth0.
OTOH, if you already have a user-sandboxed vpn working in a proxy vm
then adding the owner rule just takes one line.
Chris
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/57485F2B.1080908%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
