---------- Forwarded message ----------
From: Igor Bukanov <
ig...@mir2.org>
Date: 15 January 2013 21:32
Subject: Re: [qubes-devel] how to setup proxy in firewall vm
To: Joanna Rutkowska <
joa...@invisiblethingslab.com>
On 15 January 2013 11:23, Joanna Rutkowska
<
joa...@invisiblethingslab.com> wrote:
> Sure, but the attacks that can be conducted from a compromised netvm are
> equal to those that can be carried by an attacker controlling my WiFi
> (so, an attacker sharing a language with me at the airport, or a nearby
> room in a hotel) -- those can only be eliminated (and should be) by use
> of encrypted protocols, although even those are not a 100% panacea [1].
I missed that reasoning. Barring a bug in TCP/IP Linux stack a
compromised netvm can only influence open TCP connections or DNS UDP
packets to attack a browser in AppVM, but this is exactly what any
external router can do.
> I'm not quite follow this reasoning? Why do you think the compromised
> firewallVM cannot use the same arsenal of attacks as a compromised
> netVM?
HTTP proxy allows to move the DNS resolver outside the AppVM. This is
a reduction of the attack surface especially if one consider the
complexity of DNSSEC. Another reduction is that HTTP pipe-lining and
aggressive caching can also be implemented outside AppVM in the proxy
reducing exposure of a complex code in the browser without affecting
performance. So if the only connection to the outside world from AppVM
is through HTTP proxy, this minimizes the attack surface against AppVM
compared when the browser connects to the net without the proxy.
Now, after thinking about the default networking setup in Qubes I
realized why shared IP-based firewall makes perfect sense. The default
setup assumes that one can fully trust Linux TCP-IP stack. Under this
assumption the firewall VM can be trusted to implement the *network
isolation* between AppVMs as the only thing that it runs is the
trusted TCP/IP stack plus minimal ethernet drivers. Running a proxy in
the firewall VM violates the trust assumption. Such VM is strictly
more complex and should be less trustworthy than the default firewall
VM when implementing the network isolation.
To properly run the proxy VM one should make a proxy that can connect
between VMs without TCP/IP stack while still implementing connection
filtering. If such setup is sufficiently small, than one can trust it
more than Linux TCP/IP stack. So I have to think more about a proper
HTTP proxy setup.