Qubes
/
gsoc


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445
							<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>Giulio <giulio@gmx.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>17/07/2021, 21:52</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</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>Il 17/07/2021 21:07, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">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></blockquote>
<br>I understand. It is useful for now for me for debugging and following 
the rules flow, but I will think for something better that solve this 
problem.
<br>
<br><blockquote type=cite style="color: #007cff;">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></blockquote>
<br>Well, the last hop, such as sys-net in my last example, needs to know 
that it is the last hop. It has to set the 'srchost' and allow incoming 
connections only from the allowed ranges, while middle hops just needs 
to allow connections from the previous and the next hop. I have yet to 
look into nft enough, but I guess something else might change when 
dealing with the physical/external interface too. As for the first hop I 
have no requirements in mind so maybe that can be avoided.
<br>
<br><blockquote type=cite style="color: #007cff;"><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></blockquote>
<br>Thanks, I will think about that too.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>