Qubes
/
gsoc


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
							<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Re: GSoC Port Forwarding</title>
<link rel="important stylesheet" href="">
<style>div.headerdisplayname {font-weight:bold;}
</style></head>
<body>
<table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><div class="headerdisplayname" style="display:inline;">Oggetto: </div>Re: GSoC Port Forwarding</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Mittente: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>17/07/2021, 21:07</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">A: </div>Giulio <giulio@gmx.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hi,
<br>
<br>Le 7/17/21 à 5:31 PM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hi,
<br>thank you for the positive feedback, I really appreciate it.
<br>I spent the past couple of days digging into the "rules distribution"
<br>mechanism in the various QubesDB. It really took some time to find a
<br>better way to handle and separate the rules for each domain at every
<br>'step' of their network path.
<br>
<br><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169">https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169</a>
<br>
<br>The idea here is that each appvm will have a separate QubesDB folder on
<br>the untrusted qdb of each netvm. This is for easier cleaning and
<br>reloading, and can be used in the future when displaying the forwarding
<br>chain at each step like we were discussing with Marek in the first
<br>emails. A practical example follows.
<br>
<br>Assume the following network path:
<br>
<br><b class="moz-txt-star"><span class="moz-txt-tag">*</span>internet/lan<span class="moz-txt-tag">*</span></b> &lt;-&gt; sys-net (10.137.0.5) &lt;-&gt; sys-firewall (10.137.0.6)
<br>&lt;-&gt; sys-vpn (10.137.0.13) &lt;-&gt; sys-tor (10.137.0.14) &lt;-&gt; personal
<br>(10.137.0.10)
<br>
<br>And the following rule:
<br># qvm-firewall personal add action=forward forwardtype=external
<br>proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>Here are the QubesDB entries that are automatically added, to be
<br>consumed from the core-agent-linux:
<br>
<br>In sys-net:
<br>key = /qubes-firewall-forward/personal/10.137.0.6/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
<br>dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-firewall:
<br>key = /qubes-firewall-forward/personal/10.137.0.13/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
<br>dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-vpn:
<br>key = /qubes-firewall-forward/personal/10.137.0.14/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
<br>dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-tor:
<br>key = /qubes-firewall-forward/personal/10.137.0.10/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
<br>dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>Although this mechanism seems complex, I was not able to think of a
<br>simpler solution. Furthermore I think it is important to know which
<br>appvm is requesting the forwarding at every step, both for debugging and
<br>auditing purposes. Lastly, the next hop ip address has to be determined
<br>automatically anyway and writtem somewhere so there it is.
<br></blockquote>
<br>I've not an alternative idea yet but, I'm wondering if leaking appvm names in "higher" untrusted appvms is reasonable, especially for confidentiality. Maybe simply use the destination appvm ip, here in your example that would be personal ip. dom0/GuiVM has access to the info so getting appvm name from ip should be simple.
<br>
<br><blockquote type=cite style="color: #007cff;">I am also thinking about adding a couple of flags to let the nodes know
<br>which one is the first and which one is the last since especially the
<br>last needs additional rules for the external forwarding.
<br></blockquote>
<br>Here too, I'm not sure adding such info is a good idea for security. What exactly do you have in mind for the last needs additional rules?
<br>
<br><blockquote type=cite style="color: #007cff;">One more thing, maybe between internal hops it makes sense to randomize
<br>the forwarded ports? This way we can prevent forwarding from different
<br>appvm which shares the same network path or even just one hop from
<br>overlapping, at least internally. Does it makes sense for you?
<br></blockquote>
<br>Yes that can be some kind of useful hardening or to prevent any conflict indeed.
<br>
<br><blockquote type=cite style="color: #007cff;">Cheers
<br>Giulio
<br></blockquote>
<br>Best,
<br>Frédéric
<br>
<br></div></body>
</html>
</table></div>