63 lines
3.8 KiB
HTML
63 lines
3.8 KiB
HTML
|
<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>23/06/2021, 16:37</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>Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret <frederic.pierret@qubes-os.org></td></tr></table><br>
|
||
|
|
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
|
||
|
|
<br>thank you again for your time and the explanations, as well as the
|
||
|
|
network graph. I have now a better understanding of the overall design
|
||
|
|
and I am moving myself trhough the source code in order to think what to
|
||
|
|
place where.
|
||
|
|
<br>
|
||
|
|
<br>So, in order to translate what we discussed in practice and also check
|
||
|
|
my understanding of the code so far:
|
||
|
|
<br>
|
||
|
|
<br>1) In core-admin-client/qubesadmin/firewall.py firewall.py > The code
|
||
|
|
needs to support the new options for the rule (action=forward
|
||
|
|
frowardtype=<internal/external> srcports=443-443 srchosts=0.0.0.0/0
|
||
|
|
<br>2) In core-admin/qubes/firewall.py -> The code needs to support the same
|
||
|
|
options as the point above
|
||
|
|
<br>3) In core-admin/qubes/vm/mix/net.py -> The most important logic goes
|
||
|
|
here. Here there is the need to resolve the full network chain for
|
||
|
|
external port forwarding. From here it is possible to add the respective
|
||
|
|
rules to the QubesDB of each netvm in he chain and trigger a reload event.
|
||
|
|
<br>4) in core-agent-linux/qubesagent/firewall.py -> Here goes the logic for
|
||
|
|
building the correct syntax for iptables or nft and the actual execution
|
||
|
|
<br>
|
||
|
|
<br>Does it makes sense for you?
|
||
|
|
<br>
|
||
|
|
<br>Il 22/06/2021 16:04, Marek Marczykowski-Górecki ha scritto:
|
||
|
|
<br><blockquote type=cite style="color: #007cff;">On Tue, Jun 22, 2021 at 02:28:26PM +0200, Giulio wrote:
|
||
|
|
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">3) Since the expire= feature seems to be already implemented (and
|
||
|
|
<br>limited for the expiring full outgoing access) would it be useful to be
|
||
|
|
<br>implemented in gui and cli for every rule? I would say yes since the
|
||
|
|
<br>admin and agent code seems to be already there. The same goes for the
|
||
|
|
<br>"comment=" field.
|
||
|
|
<br></blockquote>
|
||
|
|
<br>Per-rule expire may be tricky to handle at the GUI level, I have no idea
|
||
|
|
<br>how to make the UI for this not very confusing...
|
||
|
|
<br>But the comment field is definitely useful to use.
|
||
|
|
<br>
|
||
|
|
<br></blockquote>
|
||
|
|
<br>How do you see the same checkbox that actually allows full internet
|
||
|
|
<br>access with the 5 minutes expiration time, displayed also on the window
|
||
|
|
<br>for adding a rule?
|
||
|
|
<br></blockquote>
|
||
|
|
<br>This may be more relevant to longer times. With times like 5min, just
|
||
|
|
<br>setting the rules up (if you want more than one of them) may already eat
|
||
|
|
<br>up significant portion of the expiration time...
|
||
|
|
<br>
|
||
|
|
<br></blockquote>
|
||
|
|
<br>I now totally understand your doubts, and I think the simplest solution
|
||
|
|
then would be a time/date picker, so if the user is planning anything
|
||
|
|
specific he can configure all the set of rules to the same expiration
|
||
|
|
timewithout incurring in the synchronization issues you mentioned.
|
||
|
|
<br>
|
||
|
|
<br>Cheers
|
||
|
|
<br>Giulio
|
||
|
|
<br></div></body>
|
||
|
|
</html>
|
||
|
|
</table></div>
|