Qubes/gsoc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated readme, added mails

Browse Source
This commit is contained in:
Giulio 2021-10-19 18:22:56 +02:00
parent 459b9800ea
commit 76b877f65b
46 changed files with 3018 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Readme.md
View File

@ -1,4 +1,14 @@
# QubesOS Port Forwarding GSoC 2021
## Update
Draft pull requests open for contribution and discussion have been opened in the respective repositories:
*
*
*
[Furthermore, to help future GSOC students and contributors, the full correspondance for the GSOC is now public in accordance with all the parties involved. Feel free to read there how it worked how and how the designing and development process went.](https://git.lsd.cat/Qubes/gsoc/mails)
## Final Summary
The Qubes codebase is complex but well organized and written. Simple tasks, such as the basic port forwarding do require to edit and commit to multiple different components of the ecosystem. As a new entry, a lot has to be learned before being able to understand the whole picture and thus being able to plan new fetures and write useful code. Furthermore, setting up a testing environment has proven to be somewhat hard and testing is anyway is currently a manual process and is a bit time consuming.
In this page. The original goals of this GSOC had to be scaled down in impelementing simple and straightforward port forwarding of two types via CLI only.
@ -334,4 +344,4 @@ Then, the rule processing log can be monitored running:
```
nft monitor trace
```
```

21
mails/20210611-GSoC Port Forwarding-1046.html Executable file
View File

@ -0,0 +1,21 @@
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>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>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>11/06/2021, 08:24</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 &lt;marmarek@invisiblethingslab.com&gt;, Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-western">Hello,
<br>Thank you for accepting my proposal and volunteering for mentoring me. I
spent the last weeks reading Qubes sources, documentation and mailing
lists, as well as setting up a virtual machine and attempting to prepare
a comfy development environment. I Hope by the end of the next week to
be ready to propose you a draft of the plan for the development of the
static port forwardign feature. Does that sound ok?
<br>
<br>Cheers,
<br>Giulio
<br></div></body>
</html>
</table></div>

30
mails/20210611-Re_GSoC Port Forwarding-13573.html Executable file
View File

@ -0,0 +1,30 @@
<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>11/06/2021, 09:16</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 &lt;giulio@gmx.com&gt;, 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-western">Hello,
<br>
<br>Le 6/11/21 à 8:24 AM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>Thank you for accepting my proposal and volunteering for mentoring me. I
<br>spent the last weeks reading Qubes sources, documentation and mailing
<br>lists, as well as setting up a virtual machine and attempting to prepare
<br>a comfy development environment. I Hope by the end of the next week to
<br>be ready to propose you a draft of the plan for the development of the
<br>static port forwardign feature. Does that sound ok?
<br></blockquote>
<br>Sure.
<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>

120
mails/20210620-Re_GSoC Port Forwarding-1051.html Executable file
View File

@ -0,0 +1,120 @@
<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>20/06/2021, 22:50</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;, 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-western">Hello,
<br>sorry for the late reply.
<br>
<br>I read a lot of code and I have to admit that I did not grasp the
complexity of the Admin API and networking stack before looking so much
into it. I think I've got the overall picture, but it will take a little
more to fully be confident moving there.
<br>
<br>Here is the summary of the notes I've taken from my understanding in
this week of digging.
<br>
<br>Main references:
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/admin-api/">https://www.qubes-os.org/doc/admin-api/</a>
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x">https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x</a>
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin/qubes/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Contains the classes with the parsing and formatting rules for firewall
information in the firewall XML file. It already checks proper format
for ports and ip addresses/netmask. It already support an expiry date
for a rule.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin-client/qubesadmin/tools/qvm_firewall.py<span class="moz-txt-tag">_</span></span>
<br>Class for the qvm-firewall cli tool. It is able to view, add, delete and
reload firewall rules.
<br>
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin-client/qubesadmin/firewall.py<span class="moz-txt-tag">_</span></span>
<br>The file responsible for calling Admin API (qubesd). Currently has its
own rule syntax for setting rules.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-agent-linux/qubesagent/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Is the actual file responsible for running nftables and thus
adding/deleting/reloading firewall ruless in the target firewall vm. It
also resolves DNS names for domain rules. It is run by Admin API (qubesd).
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/qubesmanager/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Contains the code for the "Firewall" tab of the "Qube Manager" window.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/ui/qubemanager.ui<span class="moz-txt-tag">_</span></span>
<br>String and properties for the "Qube Manager" UI.
<br>
<br>
<br>Questions:
<br>
<br>1) Should we both support internal port forwarding and external port
forwarding? Such as exposing a port for another domain or exposing a
port through the public network interface? I would say yes.
<br>2) Should it be possible to add rules with an 'any' clause (both tcp and
udp). I would say no because since port forwarding brings a higher
attack surface all rules should be as precise as possible.
<br>3) Since the expire= feature seems to be already implemented (and
limited for the expiring full outgoing access) would it be useful to be
implemented in gui and cli for every rule? I would say yes since the
admin and agent code seems to be already there. The same goes for the
"comment=" field.
<br>4) How would you implement the management of forwarding rules in the
network providing domain (sys-net)? Shall the user add a rule both in
the target domain (ie the one with webserver and another one in sys-net)
or should it be fully automatic from the first?
<br>5) Users should be able to set forward rules using domain names and not
static ip addresses. In this case, the actual ip addresses of the dst
domains should be collected in a similr way as currently DNS are
resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
<br>
<br>
<br>Proposed XML Syntax:
<br>&lt;rule&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;properties&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="action"&gt;forward&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="proto"&gt;udp&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/properties&gt;
<br>&lt;rule&gt;
<br>
<br>Proposed Admin API Syntax:
<br>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
timestamp&gt;] [comment=random text]
<br>
<br>I also plan to document, at least partially, the journey into this.
<br>As a last question, I'm curious what is your setup in order to test
modifications in the aforementioned repos while developing.
<br>
<br>Thank you for your time.
<br>Cheers
<br>Giulio
<br>
<br>
<br>
<br>Il 11/06/2021 09:16, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>
<br>Le 6/11/21 à 8:24 AM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>Thank you for accepting my proposal and volunteering for mentoring me. I
<br>spent the last weeks reading Qubes sources, documentation and mailing
<br>lists, as well as setting up a virtual machine and attempting to prepare
<br>a comfy development environment. I Hope by the end of the next week to
<br>be ready to propose you a draft of the plan for the development of the
<br>static port forwardign feature. Does that sound ok?
<br></blockquote>
<br>Sure.
<br>
<br><blockquote type=cite style="color: #007cff;">Cheers,
<br>Giulio
<br></blockquote>
<br>Best,
<br>Frédéric
<br>
<br></blockquote></div></body>
</html>
</table></div>

138
mails/20210622-Re_GSoC Port Forwarding-1052.html Executable file
View File

@ -0,0 +1,138 @@
<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>22/06/2021, 01:49</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;, 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-western">Hi,
<br>sorry for yesterday long and a bit confusing message. I started writing
down my documentation and progress here <a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc">https://git.lsd.cat/Qubes/gsoc</a>
so it should me more readable and easier to follow.
<br>
<br>I think my main concern now is the question 4 from the aforementioned
email. Shall the rules be automatically implemented in all 3 involved
vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
be counterintuitive to be a partially manual and partially automatic
operation. But since it actually 'automatically' exposes more attack
surface, by loosening up all 3 vms network rules, I guess that maybe
more reasoning on it would be helpful.
<br>
<br>
<br>Cheers
<br>Giulio
<br>
<br>Il 20/06/2021 22:50, Giulio ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>sorry for the late reply.
<br>
<br>I read a lot of code and I have to admit that I did not grasp the
complexity of the Admin API and networking stack before looking so much
into it. I think I've got the overall picture, but it will take a little
more to fully be confident moving there.
<br>
<br>Here is the summary of the notes I've taken from my understanding in
this week of digging.
<br>
<br>Main references:
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/admin-api/">https://www.qubes-os.org/doc/admin-api/</a>
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x">https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x</a>
<br><a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin/qubes/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Contains the classes with the parsing and formatting rules for firewall
information in the firewall XML file. It already checks proper format
for ports and ip addresses/netmask. It already support an expiry date
for a rule.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin-client/qubesadmin/tools/qvm_firewall.py<span class="moz-txt-tag">_</span></span>
<br>Class for the qvm-firewall cli tool. It is able to view, add, delete and
reload firewall rules.
<br>
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-admin-client/qubesadmin/firewall.py<span class="moz-txt-tag">_</span></span>
<br>The file responsible for calling Admin API (qubesd). Currently has its
own rule syntax for setting rules.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-agent-linux/qubesagent/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Is the actual file responsible for running nftables and thus
adding/deleting/reloading firewall ruless in the target firewall vm. It
also resolves DNS names for domain rules. It is run by Admin API (qubesd).
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/qubesmanager/firewall.py<span class="moz-txt-tag">_</span></span>
<br>Contains the code for the "Firewall" tab of the "Qube Manager" window.
<br>
<br><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/ui/qubemanager.ui<span class="moz-txt-tag">_</span></span>
<br>String and properties for the "Qube Manager" UI.
<br>
<br>
<br>Questions:
<br>
<br>1) Should we both support internal port forwarding and external port
forwarding? Such as exposing a port for another domain or exposing a
port through the public network interface? I would say yes.
<br>2) Should it be possible to add rules with an 'any' clause (both tcp and
udp). I would say no because since port forwarding brings a higher
attack surface all rules should be as precise as possible.
<br>3) Since the expire= feature seems to be already implemented (and
limited for the expiring full outgoing access) would it be useful to be
implemented in gui and cli for every rule? I would say yes since the
admin and agent code seems to be already there. The same goes for the
"comment=" field.
<br>4) How would you implement the management of forwarding rules in the
network providing domain (sys-net)? Shall the user add a rule both in
the target domain (ie the one with webserver and another one in sys-net)
or should it be fully automatic from the first?
<br>5) Users should be able to set forward rules using domain names and not
static ip addresses. In this case, the actual ip addresses of the dst
domains should be collected in a similr way as currently DNS are
resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
<br>
<br>
<br>Proposed XML Syntax:
<br>&lt;rule&gt;
<br>&nbsp;    &lt;properties&gt;
<br>&nbsp;        &lt;property name="action"&gt;forward&lt;/property&gt;
<br>&nbsp;        &lt;property name="proto"&gt;udp&lt;/property&gt;
<br>&nbsp;        &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<br>&nbsp;    &lt;/properties&gt;
<br>&lt;rule&gt;
<br>
<br>Proposed Admin API Syntax:
<br>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
timestamp&gt;] [comment=random text]
<br>
<br>I also plan to document, at least partially, the journey into this.
<br>As a last question, I'm curious what is your setup in order to test
modifications in the aforementioned repos while developing.
<br>
<br>Thank you for your time.
<br>Cheers
<br>Giulio
<br>
<br>
<br>
<br>Il 11/06/2021 09:16, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>
<br>Le 6/11/21 à 8:24 AM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>Thank you for accepting my proposal and volunteering for mentoring me. I
<br>spent the last weeks reading Qubes sources, documentation and mailing
<br>lists, as well as setting up a virtual machine and attempting to prepare
<br>a comfy development environment. I Hope by the end of the next week to
<br>be ready to propose you a draft of the plan for the development of the
<br>static port forwardign feature. Does that sound ok?
<br></blockquote>
<br>Sure.
<br>
<br><blockquote type=cite style="color: #007cff;">Cheers,
<br>Giulio
<br></blockquote>
<br>Best,
<br>Frédéric
<br>
<br></blockquote></blockquote></div></body>
</html>
</table></div>

239
mails/20210622-Re_GSoC Port Forwarding-1053.html Executable file
View File

@ -0,0 +1,239 @@
<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>22/06/2021, 14:28</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>thank you for the detailed response.
<br>
<br>Il 22/06/2021 04:43, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hi, I'm replying to both emails at once:
<br>
<br>On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
<br><blockquote type=cite style="color: #007cff;">Questions:
<br>
<br>1) Should we both support internal port forwarding and external port
<br>forwarding? Such as exposing a port for another domain or exposing a
<br>port through the public network interface? I would say yes.
<br></blockquote>
<br>Yes, I think so. Technically, those two cases should be quite similar.
<br>See also the case of sys-vpn much lower in the email.
<br>
<br></blockquote>
<br>I think that I'm actually failing to picture all the possible internal
scenarios.
<br>
<br>1) In the case of external port forwarding &lt;sys-net&gt; should forward to
&lt;sys-firewall&gt; and &lt;sys-firewall&gt; then to the &lt;appvm&gt;.
<br>In this case the port gets forwarded on the external interface ie: a LAN
or a public ip address depending on the network environment.
<br>2) In the case of internal port forwarding, the port is forwarded only
from &lt;sys-firewall&gt; to &lt;appvm&gt;. In that case, another &lt;appvm2&gt; can visit
the &lt;appvm&gt; service using &lt;sys-firewall&gt; ip address and the chosen port.
<br>In this case, the ports get exposed on &lt;sys-firewall&gt; and thus depending
on how the rules are implemented, may be available to all the AppVMs
that share the same &lt;sys-firewall&gt;.
<br>
<br>In both cases may be important to allow to specify access rules for the
forwarded port, such as the lan/public ip addresses ranges allowed for
case 1 and the appvm name for case 2.
<br>
<br><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
access with the 5 minutes expiration time, displayed also on the window
for adding a rule?
<br>However I think there is time to think more through this as the UI will
be the last component.
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">4) How would you implement the management of forwarding rules in the
<br>network providing domain (sys-net)? Shall the user add a rule both in
<br>the target domain (ie the one with webserver and another one in sys-net)
<br>or should it be fully automatic from the first?
<br></blockquote>
<br>From the user point of view, I think it should be automated as much as
<br>possible. Like, let the user choose which port in which VM redirect to
<br>where. There may be cases when such redirection won't be possible - if
<br>there is no network path between the two points.
<br>
<br></blockquote>
<br>I agree with you. We might just check when the user adds an internal
forwarding rule if both the source and the destination shares the same
&lt;firewallvm&gt;, don't we?
<br>
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">5) Users should be able to set forward rules using domain names and not
<br>static ip addresses. In this case, the actual ip addresses of the dst
<br>domains should be collected in a similr way as currently DNS are
<br>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
<br></blockquote>
<br>But here we are mostly talking about IP addresses of different VMs,
<br>right? Those can (and should) be resolved at core-admin side, so the VM
<br>applying the rules will have all the IP given. In fact VM may not be
<br>able to resolve IP of another VM at all.
<br>
<br></blockquote>
<br>Thanks for the insight, it totally makes sense.
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">Proposed XML Syntax:
<br>&lt;rule&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;properties&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="action"&gt;forward&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="proto"&gt;udp&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/properties&gt;
<br>&lt;rule&gt;
<br></blockquote>
<br>I don't see an important information here: forward to <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>where<span class="moz-txt-tag">_</span></span>.
<br>
<br><blockquote type=cite style="color: #007cff;">Proposed Admin API Syntax:
<br>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
<br>timestamp&gt;] [comment=random text]
<br></blockquote>
<br>Similar here, there needs to be a forward target (IP, and possibly a
<br>port)
<br>
<br>On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
<br><blockquote type=cite style="color: #007cff;">Since in the case of port forwarding the target ip address would always be the &lt;vmname&gt; IP address,
<br></blockquote>
<br>This is very true. But there needs to be an information where to forward
<br>the traffic to (as noted earlier). Plus, possibly a second set of ports
<br>(if you want to redirect to a different port).
<br>
<br></blockquote>
<br>I am still failing to understand something here, could you give me a an
example on when the dsthosts would different rather than the &lt;appvm&gt; or
&lt;firewallvm&gt; ip?
<br>
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">I think my main concern now is the question 4 from the aforementioned
<br>email. Shall the rules be automatically implemented in all 3 involved
<br>vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
<br>be counterintuitive to be a partially manual and partially automatic
<br>operation. But since it actually 'automatically' exposes more attack
<br>surface, by loosening up all 3 vms network rules, I guess that maybe
<br>more reasoning on it would be helpful.
<br></blockquote>
<br>Yes, but you need to pass the traffic somehow. The direct connection can
<br>be achieved with qvm-connnect-tcp (connecting to the target directly
<br>using qrexec, bypassing intermediate VMs), but it has its limits (low
<br>performance, TCP only). To keep it as actual IP traffic, you need to
<br>change firewall rules at all intermediate VMs too.
<br>
<br>Lets have a specific example: in default setup, redirect TCP port 80
<br>from the outside, to 'work' VM port 8080.
<br>
<br>The setup looks like this:
<br>&nbsp;&nbsp;
&nbsp;&nbsp; sys-net -&gt; sys-firewall -&gt; work
<br>
<br>For this, you will need those rules:
<br>
<br>1. In sys-net: forward TCP port 80 to sys-firewall
<br>2. In sys-firewall: forward TCP port 80 to work, port 8080
<br>3. In work: allow TCP port 8080
<br>
<br>Now is the important design question: how to store those rules? If you
<br>store them at all three places separately, it
<br>will be easier to apply them at runtime, but it will be harder to
<br>correlate them in UI. Plus, if any of them get modified/removed, it may
<br>be non-trivial to troubleshoot the issue.
<br>The other approach is to store the forward rules only in one place (the
<br>target, 'work' in this example? or the source, 'sys-net' here?). This
<br>way, it's harder to mess thing up. But when applying the rules (building
<br>rule sets for qubes-firewall service in all the involved VMs), you need
<br>to check several places.
<br>Plus, the UI should clearly show such redirected ports at all involved
<br>places, because it does affect system security - it must be easy to spot
<br>if any redirects are enabled.
<br>
<br>
<br>To make things more complex (sorry...), there may be a VPN or other
<br>proxy service (Tor?) involved. For example:
<br>
<br>sys-net -&gt; sys-firewall -&gt; sys-vpn -&gt; work
<br>
<br>In such a case, the "external" VM for 'work' is not really sys-net, but
<br>rather sys-vpn. And actually you need to be careful to not accidentally
<br>bypass VPN either by allowing 'work' to communicate outside of the VPN,
<br>or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
<br>
<br>This case is not easy to solve, because currently core-admin has no idea
<br>whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
<br>need to (finally) introduce some flag to mark such VMs?
<br>
<br>
<br>And another question: what should happen if you change netvm of 'work'.
<br>For example switch to something like:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp; sys-net -&gt; sys-firewall -&gt; (other VMs, but not 'work')
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp; sys-wifi -&gt; work
<br>
<br>Should the redirection stay active via sys-wifi? I think it should not,
<br>at least not automatically (maybe have an option for that?).
<br>
<br></blockquote>
<br>I understand all of your points and consequently it is hard to figure
out a catch-all solution.
<br>
<br>I tried charting the flow of the possible solution.
<br><a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png">https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png</a>
<br>
<br>As a sum up:
<br>1) Rules are stored only in &lt;appvm&gt;/firewall.xml
<br>2) Rules can either be internal or exteranl (ie: they are applied only
to &lt;firewallvm&gt; or both to &lt;firewallvm&gt; and its &lt;netvm&gt;)
<br>3) Forwarding rules should be purged if &lt;appvm&gt; changes &lt;firewall&gt;
(maybe also if &lt;firewallvm&gt; changes &lt;netvm&gt;? But that would be harde to
detect I guess)
<br>4) Users should be able to specify both the forwarded port and
destination port as you were saying
<br>5) Users should be able to eventually restrict forwarding to designated
networks (with 0.0.0.0/0 being the wildcard instead of being a wildcard
by default)
<br>
<br>However, in this case it will surely be harder to display the rules in
all the affected vms.
<br>The other approach, as you were suggesting, of adding each specific rule
in each vm conf does make sense, but I think then it would necessary
something to keep track of the rule dependencies (such as a unique
identifier). Furthermore there is a higher risk of having orphaned rules
or a inconsistent state.
<br>
<br>Furthermore, in the "internal" vpn case that I have in mind, the idea is
to forward the local port via the VPN interface or Tor (but in the Tor
case users should just stick to Whonix). Some providers, such as
Mullvad, AirVPN, PIA etc allows port forwarding this way and I think
that's the most relevant case since it allows exposing a service on the
internet while maintaining a bit of privacy/anonimity and whithout
needing to bypass the local network NAT. Is this the same case you are
referring to?
<br>
<br><blockquote type=cite style="color: #007cff;">And finally, don't forget IPv6 exists. Which means you can have the same
<br>port on IPv4 and IPv6. And theoretically they could be redirected to
<br>different places (but I'm not sure if that's a good idea...).
<br>
<br></blockquote>
<br>I think that once we have figured out the overall logic to implement, it
should not be hard to duplicate it for ipv4/ipv6. I think the main
problem to think about is to insert proper checks to prevent users from
adding mixed rules.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

253
mails/20210622-Re_GSoC Port Forwarding-13692.html Executable file
View File

@ -0,0 +1,253 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/06/2021, 04:43</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
Hi, I'm replying to both emails at once:
On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>sorry for the late reply.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I read a lot of code and I have to admit that I did not grasp the
<span class="moz-txt-citetags">&gt; </span>complexity of the Admin API and networking stack before looking so much
<span class="moz-txt-citetags">&gt; </span>into it. I think I've got the overall picture, but it will take a little
<span class="moz-txt-citetags">&gt; </span>more to fully be confident moving there.
</pre></blockquote><pre wrap class="moz-quote-pre">
(...)
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>core-agent-linux/qubesagent/firewall.py<span class="moz-txt-tag">_</span></span>
<span class="moz-txt-citetags">&gt; </span>Is the actual file responsible for running nftables and thus
<span class="moz-txt-citetags">&gt; </span>adding/deleting/reloading firewall ruless in the target firewall vm. It
<span class="moz-txt-citetags">&gt; </span>also resolves DNS names for domain rules. It is run by Admin API (qubesd).
</pre></blockquote><pre wrap class="moz-quote-pre">
This file is run as part of the qubes-firewall service in relevant VMs
(especially sys-firewall).
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/qubesmanager/firewall.py<span class="moz-txt-tag">_</span></span>
<span class="moz-txt-citetags">&gt; </span>Contains the code for the "Firewall" tab of the "Qube Manager" window.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span><span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>manager/ui/qubemanager.ui<span class="moz-txt-tag">_</span></span>
<span class="moz-txt-citetags">&gt; </span>String and properties for the "Qube Manager" UI.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Questions:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>1) Should we both support internal port forwarding and external port
<span class="moz-txt-citetags">&gt; </span>forwarding? Such as exposing a port for another domain or exposing a
<span class="moz-txt-citetags">&gt; </span>port through the public network interface? I would say yes.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, I think so. Technically, those two cases should be quite similar.
See also the case of sys-vpn much lower in the email.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>2) Should it be possible to add rules with an 'any' clause (both tcp and
<span class="moz-txt-citetags">&gt; </span>udp). I would say no because since port forwarding brings a higher
<span class="moz-txt-citetags">&gt; </span>attack surface all rules should be as precise as possible.
</pre></blockquote><pre wrap class="moz-quote-pre">
Indeed. Furthermore, most services are either TCP or UDP, very few are
both (and for those, it's ok to require two rules).
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>3) Since the expire= feature seems to be already implemented (and
<span class="moz-txt-citetags">&gt; </span>limited for the expiring full outgoing access) would it be useful to be
<span class="moz-txt-citetags">&gt; </span>implemented in gui and cli for every rule? I would say yes since the
<span class="moz-txt-citetags">&gt; </span>admin and agent code seems to be already there. The same goes for the
<span class="moz-txt-citetags">&gt; </span>"comment=" field.
</pre></blockquote><pre wrap class="moz-quote-pre">
Per-rule expire may be tricky to handle at the GUI level, I have no idea
how to make the UI for this not very confusing...
But the comment field is definitely useful to use.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>4) How would you implement the management of forwarding rules in the
<span class="moz-txt-citetags">&gt; </span>network providing domain (sys-net)? Shall the user add a rule both in
<span class="moz-txt-citetags">&gt; </span>the target domain (ie the one with webserver and another one in sys-net)
<span class="moz-txt-citetags">&gt; </span>or should it be fully automatic from the first?
</pre></blockquote><pre wrap class="moz-quote-pre">
From the user point of view, I think it should be automated as much as
possible. Like, let the user choose which port in which VM redirect to
where. There may be cases when such redirection won't be possible - if
there is no network path between the two points.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>5) Users should be able to set forward rules using domain names and not
<span class="moz-txt-citetags">&gt; </span>static ip addresses. In this case, the actual ip addresses of the dst
<span class="moz-txt-citetags">&gt; </span>domains should be collected in a similr way as currently DNS are
<span class="moz-txt-citetags">&gt; </span>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
</pre></blockquote><pre wrap class="moz-quote-pre">
But here we are mostly talking about IP addresses of different VMs,
right? Those can (and should) be resolved at core-admin side, so the VM
applying the rules will have all the IP given. In fact VM may not be
able to resolve IP of another VM at all.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Proposed XML Syntax:
<span class="moz-txt-citetags">&gt; </span>&lt;rule&gt;
<span class="moz-txt-citetags">&gt; </span> &lt;properties&gt;
<span class="moz-txt-citetags">&gt; </span> &lt;property name="action"&gt;forward&lt;/property&gt;
<span class="moz-txt-citetags">&gt; </span> &lt;property name="proto"&gt;udp&lt;/property&gt;
<span class="moz-txt-citetags">&gt; </span> &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<span class="moz-txt-citetags">&gt; </span> &lt;/properties&gt;
<span class="moz-txt-citetags">&gt; </span>&lt;rule&gt;
</pre></blockquote><pre wrap class="moz-quote-pre">
I don't see an important information here: forward to <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>where<span class="moz-txt-tag">_</span></span>.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Proposed Admin API Syntax:
<span class="moz-txt-citetags">&gt; </span>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
<span class="moz-txt-citetags">&gt; </span>timestamp&gt;] [comment=random text]
</pre></blockquote><pre wrap class="moz-quote-pre">
Similar here, there needs to be a forward target (IP, and possibly a
port)
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I also plan to document, at least partially, the journey into this.
<span class="moz-txt-citetags">&gt; </span>As a last question, I'm curious what is your setup in order to test
<span class="moz-txt-citetags">&gt; </span>modifications in the aforementioned repos while developing.
</pre></blockquote><pre wrap class="moz-quote-pre">
In practice, I have a separate (physical) computer to run various tests.
It can be a system installed on an external disk. But there are also
other options:
1. Test on the system you are developing on - this may be the easiest
option, but is also a risky one (it is easy to break things - may be
undesirable if you need that system for other stuff too).
2. Test in a virtual machine - it's possible to run Qubes OS inside KVM
with nested virtualization enabled (included emulated IOMMU - sadly
works only Intel only). This requires non-Qubes host. While it is
possible to run Qubes inside Qubes, the setup is quite challenging and
fragile, so I don't recommend this path.
3. As a last resort, I have a bunch test systems and I can give you
access to one of them via SSH. But developing network-related changes,
accessing the system through network, may not be the wisest thing to
do...
You can also find some helpful info here:
<a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/#debugging">https://www.qubes-os.org/doc/#debugging</a>
On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hi,
<span class="moz-txt-citetags">&gt; </span>sorry for yesterday long and a bit confusing message. I started writing
<span class="moz-txt-citetags">&gt; </span>down my documentation and progress here <a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc">https://git.lsd.cat/Qubes/gsoc</a>
<span class="moz-txt-citetags">&gt; </span>so it should me more readable and easier to follow.
</pre></blockquote><pre wrap class="moz-quote-pre">
No worries. Some comments for this page:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>qvm-firewall &lt;vmname&gt; add action=accept dsthost=1.1.1.1 proto=tcp dstports=80-80 command="cloudflare http test rule" expire=+5000
</pre></blockquote><pre wrap class="moz-quote-pre">
It's "comment", not "command". And also, if you ever need to write Admin
API level line manually, the comment field must be last.
(but on qvm-firewall cmdline it is fine as is)
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Since in the case of port forwarding the target ip address would always be the &lt;vmname&gt; IP address,
</pre></blockquote><pre wrap class="moz-quote-pre">
This is very true. But there needs to be an information where to forward
the traffic to (as noted earlier). Plus, possibly a second set of ports
(if you want to redirect to a different port).
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>I think my main concern now is the question 4 from the aforementioned
<span class="moz-txt-citetags">&gt; </span>email. Shall the rules be automatically implemented in all 3 involved
<span class="moz-txt-citetags">&gt; </span>vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
<span class="moz-txt-citetags">&gt; </span>be counterintuitive to be a partially manual and partially automatic
<span class="moz-txt-citetags">&gt; </span>operation. But since it actually 'automatically' exposes more attack
<span class="moz-txt-citetags">&gt; </span>surface, by loosening up all 3 vms network rules, I guess that maybe
<span class="moz-txt-citetags">&gt; </span>more reasoning on it would be helpful.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, but you need to pass the traffic somehow. The direct connection can
be achieved with qvm-connnect-tcp (connecting to the target directly
using qrexec, bypassing intermediate VMs), but it has its limits (low
performance, TCP only). To keep it as actual IP traffic, you need to
change firewall rules at all intermediate VMs too.
Lets have a specific example: in default setup, redirect TCP port 80
from the outside, to 'work' VM port 8080.
The setup looks like this:
sys-net -&gt; sys-firewall -&gt; work
For this, you will need those rules:
1. In sys-net: forward TCP port 80 to sys-firewall
2. In sys-firewall: forward TCP port 80 to work, port 8080
3. In work: allow TCP port 8080
Now is the important design question: how to store those rules? If you
store them at all three places separately, it
will be easier to apply them at runtime, but it will be harder to
correlate them in UI. Plus, if any of them get modified/removed, it may
be non-trivial to troubleshoot the issue.
The other approach is to store the forward rules only in one place (the
target, 'work' in this example? or the source, 'sys-net' here?). This
way, it's harder to mess thing up. But when applying the rules (building
rule sets for qubes-firewall service in all the involved VMs), you need
to check several places.
Plus, the UI should clearly show such redirected ports at all involved
places, because it does affect system security - it must be easy to spot
if any redirects are enabled.
To make things more complex (sorry...), there may be a VPN or other
proxy service (Tor?) involved. For example:
sys-net -&gt; sys-firewall -&gt; sys-vpn -&gt; work
In such a case, the "external" VM for 'work' is not really sys-net, but
rather sys-vpn. And actually you need to be careful to not accidentally
bypass VPN either by allowing 'work' to communicate outside of the VPN,
or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
This case is not easy to solve, because currently core-admin has no idea
whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
need to (finally) introduce some flag to mark such VMs?
And another question: what should happen if you change netvm of 'work'.
For example switch to something like:
sys-net -&gt; sys-firewall -&gt; (other VMs, but not 'work')
sys-wifi -&gt; work
Should the redirection stay active via sys-wifi? I think it should not,
at least not automatically (maybe have an option for that?).
And finally, don't forget IPv6 exists. Which means you can have the same
port on IPv4 and IPv6. And theoretically they could be redirected to
different places (but I'm not sure if that's a good idea...).
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

395
mails/20210622-Re_GSoC Port Forwarding-13697.html Executable file
View File

@ -0,0 +1,395 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/06/2021, 16:04</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Tue, Jun 22, 2021 at 02:28:26PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>thank you for the detailed response.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Il 22/06/2021 04:43, Marek Marczykowski-Górecki ha scritto:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>Hi, I'm replying to both emails at once:
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Questions:
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>1) Should we both support internal port forwarding and external port
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>forwarding? Such as exposing a port for another domain or exposing a
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>port through the public network interface? I would say yes.
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Yes, I think so. Technically, those two cases should be quite similar.
<span class="moz-txt-citetags">&gt; &gt; </span>See also the case of sys-vpn much lower in the email.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I think that I'm actually failing to picture all the possible internal
<span class="moz-txt-citetags">&gt; </span>scenarios.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>1) In the case of external port forwarding &lt;sys-net&gt; should forward to
<span class="moz-txt-citetags">&gt; </span>&lt;sys-firewall&gt; and &lt;sys-firewall&gt; then to the &lt;appvm&gt;.
<span class="moz-txt-citetags">&gt; </span>In this case the port gets forwarded on the external interface ie: a LAN
<span class="moz-txt-citetags">&gt; </span>or a public ip address depending on the network environment.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>2) In the case of internal port forwarding, the port is forwarded only
<span class="moz-txt-citetags">&gt; </span>from &lt;sys-firewall&gt; to &lt;appvm&gt;. In that case, another &lt;appvm2&gt; can visit
<span class="moz-txt-citetags">&gt; </span>the &lt;appvm&gt; service using &lt;sys-firewall&gt; ip address and the chosen port.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>In this case, the ports get exposed on &lt;sys-firewall&gt; and thus depending
<span class="moz-txt-citetags">&gt; </span>on how the rules are implemented, may be available to all the AppVMs
<span class="moz-txt-citetags">&gt; </span>that share the same &lt;sys-firewall&gt;.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>In both cases may be important to allow to specify access rules for the
<span class="moz-txt-citetags">&gt; </span>forwarded port, such as the lan/public ip addresses ranges allowed for
<span class="moz-txt-citetags">&gt; </span>case 1 and the appvm name for case 2.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, indeed.
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>3) Since the expire= feature seems to be already implemented (and
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>limited for the expiring full outgoing access) would it be useful to be
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>implemented in gui and cli for every rule? I would say yes since the
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>admin and agent code seems to be already there. The same goes for the
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>"comment=" field.
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Per-rule expire may be tricky to handle at the GUI level, I have no idea
<span class="moz-txt-citetags">&gt; &gt; </span>how to make the UI for this not very confusing...
<span class="moz-txt-citetags">&gt; &gt; </span>But the comment field is definitely useful to use.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>How do you see the same checkbox that actually allows full internet
<span class="moz-txt-citetags">&gt; </span>access with the 5 minutes expiration time, displayed also on the window
<span class="moz-txt-citetags">&gt; </span>for adding a rule?
</pre></blockquote><pre wrap class="moz-quote-pre">
This may be more relevant to longer times. With times like 5min, just
setting the rules up (if you want more than one of them) may already eat
up significant portion of the expiration time...
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>However I think there is time to think more through this as the UI will
<span class="moz-txt-citetags">&gt; </span>be the last component.
<span class="moz-txt-citetags">&gt; </span>
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>4) How would you implement the management of forwarding rules in the
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>network providing domain (sys-net)? Shall the user add a rule both in
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>the target domain (ie the one with webserver and another one in sys-net)
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>or should it be fully automatic from the first?
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>From the user point of view, I think it should be automated as much as
<span class="moz-txt-citetags">&gt; &gt; </span>possible. Like, let the user choose which port in which VM redirect to
<span class="moz-txt-citetags">&gt; &gt; </span>where. There may be cases when such redirection won't be possible - if
<span class="moz-txt-citetags">&gt; &gt; </span>there is no network path between the two points.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I agree with you. We might just check when the user adds an internal
<span class="moz-txt-citetags">&gt; </span>forwarding rule if both the source and the destination shares the same
<span class="moz-txt-citetags">&gt; </span>&lt;firewallvm&gt;, don't we?
</pre></blockquote><pre wrap class="moz-quote-pre">
I think we can simplify it even further: allow forwarding ports only
from (any of) upstream VMs. For example in this case:
appvm1 -&gt; sys-firewall -&gt; sys-net
| |
appvm2 ------+ |
|
appvm3 -&gt; some-other-firewall -+
Allow forwarding to appvm1 only from sys-net (external case) or
sys-firwall, but not appvm3 or some-other-firewall.
Then, within the forward rule configuration you can restrict access
rules (like you propose below, with default 0.0.0.0/0). This restriction
will work for VMs directly connected to sys-firewall only, because there
is NAT (sys-net does not know whether its appvm1 or appvm2 - it only
sees sys-firewall IP in those cases). But I think it's ok to make this
limitation and require VMs to be connected to the same &lt;firewallvm&gt; if
you want to forward traffic between them.
I think you did it right with the internal/external type.
Allowing forwarding from others (like some-other-firewall in the picture
above) may be tricky (and unreliable), as it will be hard to restrict
who can really connect (sys-net have no idea which VM behind
sys-firewall/some-other-firewall really connects).
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>5) Users should be able to set forward rules using domain names and not
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>static ip addresses. In this case, the actual ip addresses of the dst
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>domains should be collected in a similr way as currently DNS are
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>But here we are mostly talking about IP addresses of different VMs,
<span class="moz-txt-citetags">&gt; &gt; </span>right? Those can (and should) be resolved at core-admin side, so the VM
<span class="moz-txt-citetags">&gt; &gt; </span>applying the rules will have all the IP given. In fact VM may not be
<span class="moz-txt-citetags">&gt; &gt; </span>able to resolve IP of another VM at all.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Thanks for the insight, it totally makes sense.
<span class="moz-txt-citetags">&gt; </span>
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Proposed XML Syntax:
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>&lt;rule&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;properties&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="action"&gt;forward&lt;/property&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="proto"&gt;udp&lt;/property&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span> &lt;/properties&gt;
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>&lt;rule&gt;
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>I don't see an important information here: forward to <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>where<span class="moz-txt-tag">_</span></span>.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Proposed Admin API Syntax:
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>timestamp&gt;] [comment=random text]
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Similar here, there needs to be a forward target (IP, and possibly a
<span class="moz-txt-citetags">&gt; &gt; </span>port)
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Since in the case of port forwarding the target ip address would always be the &lt;vmname&gt; IP address,
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>This is very true. But there needs to be an information where to forward
<span class="moz-txt-citetags">&gt; &gt; </span>the traffic to (as noted earlier). Plus, possibly a second set of ports
<span class="moz-txt-citetags">&gt; &gt; </span>(if you want to redirect to a different port).
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I am still failing to understand something here, could you give me a an
<span class="moz-txt-citetags">&gt; </span>example on when the dsthosts would different rather than the &lt;appvm&gt; or
<span class="moz-txt-citetags">&gt; </span>&lt;firewallvm&gt; ip?
</pre></blockquote><pre wrap class="moz-quote-pre">
I'm talking about the other end of the connection. Let me summarize
this for different rules:
1. For allow/deny rules, it is about where the VM can connect to -
outgoing connection. The source IP is always the VM's IP (implicitly),
and the rule can specify destination IP, protocol, port.
2. For forward rules, it is about incoming connection - the destination
IP is VM's IP (implicitly), but then the connection is redirected to
somewhere else (like some appvm) - and the rule needs to point out to
where it should redirect.
If you have simplified case like this:
sys-net -&gt; appvm
Then, the rule in sys-net not only needs to know what to redirect (like,
TCP port 80), but also needs to know to redirect it to appvm, not
anywhere else.
Similarly, if the rule is stored with appvm, it needs to know to
install the redirect in sys-net and not some intermediate other VM (as
talked about internal, or VPN or Tor cases).
Ok, reading your response further, I think you covered it with
external/internal type, so it should be good.
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>I think my main concern now is the question 4 from the aforementioned
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>email. Shall the rules be automatically implemented in all 3 involved
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>be counterintuitive to be a partially manual and partially automatic
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>operation. But since it actually 'automatically' exposes more attack
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>surface, by loosening up all 3 vms network rules, I guess that maybe
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>more reasoning on it would be helpful.
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Yes, but you need to pass the traffic somehow. The direct connection can
<span class="moz-txt-citetags">&gt; &gt; </span>be achieved with qvm-connnect-tcp (connecting to the target directly
<span class="moz-txt-citetags">&gt; &gt; </span>using qrexec, bypassing intermediate VMs), but it has its limits (low
<span class="moz-txt-citetags">&gt; &gt; </span>performance, TCP only). To keep it as actual IP traffic, you need to
<span class="moz-txt-citetags">&gt; &gt; </span>change firewall rules at all intermediate VMs too.
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Lets have a specific example: in default setup, redirect TCP port 80
<span class="moz-txt-citetags">&gt; &gt; </span>from the outside, to 'work' VM port 8080.
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>The setup looks like this:
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span> sys-net -&gt; sys-firewall -&gt; work
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>For this, you will need those rules:
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>1. In sys-net: forward TCP port 80 to sys-firewall
<span class="moz-txt-citetags">&gt; &gt; </span>2. In sys-firewall: forward TCP port 80 to work, port 8080
<span class="moz-txt-citetags">&gt; &gt; </span>3. In work: allow TCP port 8080
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Now is the important design question: how to store those rules? If you
<span class="moz-txt-citetags">&gt; &gt; </span>store them at all three places separately, it
<span class="moz-txt-citetags">&gt; &gt; </span>will be easier to apply them at runtime, but it will be harder to
<span class="moz-txt-citetags">&gt; &gt; </span>correlate them in UI. Plus, if any of them get modified/removed, it may
<span class="moz-txt-citetags">&gt; &gt; </span>be non-trivial to troubleshoot the issue.
<span class="moz-txt-citetags">&gt; &gt; </span>The other approach is to store the forward rules only in one place (the
<span class="moz-txt-citetags">&gt; &gt; </span>target, 'work' in this example? or the source, 'sys-net' here?). This
<span class="moz-txt-citetags">&gt; &gt; </span>way, it's harder to mess thing up. But when applying the rules (building
<span class="moz-txt-citetags">&gt; &gt; </span>rule sets for qubes-firewall service in all the involved VMs), you need
<span class="moz-txt-citetags">&gt; &gt; </span>to check several places.
<span class="moz-txt-citetags">&gt; &gt; </span>Plus, the UI should clearly show such redirected ports at all involved
<span class="moz-txt-citetags">&gt; &gt; </span>places, because it does affect system security - it must be easy to spot
<span class="moz-txt-citetags">&gt; &gt; </span>if any redirects are enabled.
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>To make things more complex (sorry...), there may be a VPN or other
<span class="moz-txt-citetags">&gt; &gt; </span>proxy service (Tor?) involved. For example:
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>sys-net -&gt; sys-firewall -&gt; sys-vpn -&gt; work
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>In such a case, the "external" VM for 'work' is not really sys-net, but
<span class="moz-txt-citetags">&gt; &gt; </span>rather sys-vpn. And actually you need to be careful to not accidentally
<span class="moz-txt-citetags">&gt; &gt; </span>bypass VPN either by allowing 'work' to communicate outside of the VPN,
<span class="moz-txt-citetags">&gt; &gt; </span>or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>This case is not easy to solve, because currently core-admin has no idea
<span class="moz-txt-citetags">&gt; &gt; </span>whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
<span class="moz-txt-citetags">&gt; &gt; </span>need to (finally) introduce some flag to mark such VMs?
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>And another question: what should happen if you change netvm of 'work'.
<span class="moz-txt-citetags">&gt; &gt; </span>For example switch to something like:
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span> sys-net -&gt; sys-firewall -&gt; (other VMs, but not 'work')
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span> sys-wifi -&gt; work
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Should the redirection stay active via sys-wifi? I think it should not,
<span class="moz-txt-citetags">&gt; &gt; </span>at least not automatically (maybe have an option for that?).
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I understand all of your points and consequently it is hard to figure
<span class="moz-txt-citetags">&gt; </span>out a catch-all solution.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I tried charting the flow of the possible solution.
<span class="moz-txt-citetags">&gt; </span><a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png">https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png</a>
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>As a sum up:
<span class="moz-txt-citetags">&gt; </span>1) Rules are stored only in &lt;appvm&gt;/firewall.xml
<span class="moz-txt-citetags">&gt; </span>2) Rules can either be internal or exteranl (ie: they are applied only
<span class="moz-txt-citetags">&gt; </span>to &lt;firewallvm&gt; or both to &lt;firewallvm&gt; and its &lt;netvm&gt;)
</pre></blockquote><pre wrap class="moz-quote-pre">
Please note there may be more VMs in between, some examples at:
<a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
So, I think it's better to define it as:
1. internal: redirect from immediate parent only (VM's 'netvm' property)
2. external: redirect on the whole chain up to the top (follow 'netvm'
property until you get a VM with it set to None).
My idea of redirect source was to explicitly point where the redirection
starts, instead of this automatic internal/external. But indeed the
automatic may be easier to use.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>3) Forwarding rules should be purged if &lt;appvm&gt; changes &lt;firewall&gt;
<span class="moz-txt-citetags">&gt; </span>(maybe also if &lt;firewallvm&gt; changes &lt;netvm&gt;? But that would be harde to
<span class="moz-txt-citetags">&gt; </span>detect I guess)
</pre></blockquote><pre wrap class="moz-quote-pre">
Or maybe it should be configurable? I'd hate to loose the configuration just
because I temporarily switched to another netvm (and then switched it
back)...
Or, allow both automatic internal/external and explicit redirect source.
Then, setting redirect type to 'internal' would set the redirect point to
the VM's direct upstream (and would automatically adjust if you change
netvm), setting to 'external' would follow the whole chain. But setting
to explicit sys-net for example would always try to apply rule there, if
reachable (and add no rules, if not reachable).
Does it make sense?
Maybe let me explain it on a diagram (see attachment). Especially see
how redirections to appvm3 has changed after switching it from sys-vpn
to sys-firewall: the "internal" redirection (in green) remained there,
but the "sys-vpn" one (in blue) did not.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>4) Users should be able to specify both the forwarded port and
<span class="moz-txt-citetags">&gt; </span>destination port as you were saying
<span class="moz-txt-citetags">&gt; </span>5) Users should be able to eventually restrict forwarding to designated
<span class="moz-txt-citetags">&gt; </span>networks (with 0.0.0.0/0 being the wildcard instead of being a wildcard
<span class="moz-txt-citetags">&gt; </span>by default)
</pre></blockquote><pre wrap class="moz-quote-pre">
I wonder if this should be combined in the same rule, or maybe separate
rule for limiting? But maybe indeed putting it into the same rule may be
easier (avoids duplicating port numbers etc).
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>However, in this case it will surely be harder to display the rules in
<span class="moz-txt-citetags">&gt; </span>all the affected vms.
<span class="moz-txt-citetags">&gt; </span>The other approach, as you were suggesting, of adding each specific rule
<span class="moz-txt-citetags">&gt; </span>in each vm conf does make sense, but I think then it would necessary
<span class="moz-txt-citetags">&gt; </span>something to keep track of the rule dependencies (such as a unique
<span class="moz-txt-citetags">&gt; </span>identifier). Furthermore there is a higher risk of having orphaned rules
<span class="moz-txt-citetags">&gt; </span>or a inconsistent state.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Furthermore, in the "internal" vpn case that I have in mind, the idea is
<span class="moz-txt-citetags">&gt; </span>to forward the local port via the VPN interface or Tor (but in the Tor
<span class="moz-txt-citetags">&gt; </span>case users should just stick to Whonix). Some providers, such as
<span class="moz-txt-citetags">&gt; </span>Mullvad, AirVPN, PIA etc allows port forwarding this way and I think
<span class="moz-txt-citetags">&gt; </span>that's the most relevant case since it allows exposing a service on the
<span class="moz-txt-citetags">&gt; </span>internet while maintaining a bit of privacy/anonimity and whithout
<span class="moz-txt-citetags">&gt; </span>needing to bypass the local network NAT. Is this the same case you are
<span class="moz-txt-citetags">&gt; </span>referring to?
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, exactly.
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>And finally, don't forget IPv6 exists. Which means you can have the same
<span class="moz-txt-citetags">&gt; &gt; </span>port on IPv4 and IPv6. And theoretically they could be redirected to
<span class="moz-txt-citetags">&gt; &gt; </span>different places (but I'm not sure if that's a good idea...).
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I think that once we have figured out the overall logic to implement, it
<span class="moz-txt-citetags">&gt; </span>should not be hard to duplicate it for ipv4/ipv6. I think the main
<span class="moz-txt-citetags">&gt; </span>problem to think about is to insert proper checks to prevent users from
<span class="moz-txt-citetags">&gt; </span>adding mixed rules.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, that sounds about right.
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div>
</fieldset>
</pre></div><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages/0.jpg"></DIV><br><hr><br><div style="font-size:12px;color:black;"><img src="data:image/gif;base64,R0lGODdhDwAPAOMAAP///zEwYmJlzQAAAPr6+vv7+/7+/vb29pyZ//39/YOBg////////////////////ywAAAAADwAPAAAESRDISUG4lQYr+s5bIEwDUWictA2GdBjhaAGDrKZzjYq3PgUw2co24+VGLYAAAesRLQklxoeiUDUI0qSj6EoH4Iuoq6B0PQJyJQIAOw==">
<ul><li><a href="Attachments/network-graph.jpg">Attachments/network-graph.jpg</li></a></ul></div><div class='' ></div></body>
</html>

63
mails/20210623-Re_GSoC Port Forwarding-1054.html Executable file
View File

@ -0,0 +1,63 @@
<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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</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 &gt; The code
needs to support the new options for the rule (action=forward
frowardtype=&lt;internal/external&gt; srcports=443-443 srchosts=0.0.0.0/0
<br>2) In core-admin/qubes/firewall.py -&gt; The code needs to support the same
options as the point above
<br>3) In core-admin/qubes/vm/mix/net.py -&gt; 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 -&gt; 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&nbsp; incurring in the synchronization issues you mentioned.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

54
mails/20210623-Re_GSoC Port Forwarding-13708.html Executable file
View File

@ -0,0 +1,54 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>23/06/2021, 23:11</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Wed, Jun 23, 2021 at 04:37:20PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>thank you again for your time and the explanations, as well as the
<span class="moz-txt-citetags">&gt; </span>network graph. I have now a better understanding of the overall design
<span class="moz-txt-citetags">&gt; </span>and I am moving myself trhough the source code in order to think what to
<span class="moz-txt-citetags">&gt; </span>place where.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>So, in order to translate what we discussed in practice and also check
<span class="moz-txt-citetags">&gt; </span>my understanding of the code so far:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>1) In core-admin-client/qubesadmin/firewall.py firewall.py &gt; The code
<span class="moz-txt-citetags">&gt; </span>needs to support the new options for the rule (action=forward
<span class="moz-txt-citetags">&gt; </span>frowardtype=&lt;internal/external&gt; srcports=443-443 srchosts=0.0.0.0/0
<span class="moz-txt-citetags">&gt; </span>2) In core-admin/qubes/firewall.py -&gt; The code needs to support the same
<span class="moz-txt-citetags">&gt; </span>options as the point above
<span class="moz-txt-citetags">&gt; </span>3) In core-admin/qubes/vm/mix/net.py -&gt; The most important logic goes
<span class="moz-txt-citetags">&gt; </span>here. Here there is the need to resolve the full network chain for
<span class="moz-txt-citetags">&gt; </span>external port forwarding. From here it is possible to add the respective
<span class="moz-txt-citetags">&gt; </span>rules to the QubesDB of each netvm in he chain and trigger a reload event.
<span class="moz-txt-citetags">&gt; </span>4) in core-agent-linux/qubesagent/firewall.py -&gt; Here goes the logic for
<span class="moz-txt-citetags">&gt; </span>building the correct syntax for iptables or nft and the actual execution
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Does it makes sense for you?
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, I think you got this perfectly correct.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>I now totally understand your doubts, and I think the simplest solution
<span class="moz-txt-citetags">&gt; </span>then would be a time/date picker, so if the user is planning anything
<span class="moz-txt-citetags">&gt; </span>specific he can configure all the set of rules to the same expiration
<span class="moz-txt-citetags">&gt; </span>timewithout incurring in the synchronization issues you mentioned.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, that could work, with some easy way to use the same time for
multiple rules (for example default to the last choice).
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

53
mails/20210628-Re_GSoC Port Forwarding-1058.html Executable file
View File

@ -0,0 +1,53 @@
<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>28/06/2021, 22:46</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">On 6/23/21 11:11 PM, Marek Marczykowski-Górecki wrote:
<br><blockquote type=cite style="color: #007cff;">On Wed, Jun 23, 2021 at 04:37:20PM +0200, Giulio wrote:
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>thank you again for your time and the explanations, as well as the
<br>network graph. I have now a better understanding of the overall design
<br>and I am moving myself trhough the source code in order to think what to
<br>place where.
<br>
<br>So, in order to translate what we discussed in practice and also check
<br>my understanding of the code so far:
<br>
<br>1) In core-admin-client/qubesadmin/firewall.py firewall.py &gt; The code
<br>needs to support the new options for the rule (action=forward
<br>frowardtype=&lt;internal/external&gt; srcports=443-443 srchosts=0.0.0.0/0
<br>2) In core-admin/qubes/firewall.py -&gt; The code needs to support the same
<br>options as the point above
<br>3) In core-admin/qubes/vm/mix/net.py -&gt; The most important logic goes
<br>here. Here there is the need to resolve the full network chain for
<br>external port forwarding. From here it is possible to add the respective
<br>rules to the QubesDB of each netvm in he chain and trigger a reload event.
<br>4) in core-agent-linux/qubesagent/firewall.py -&gt; Here goes the logic for
<br>building the correct syntax for iptables or nft and the actual execution
<br>
<br>Does it makes sense for you?
<br></blockquote>
<br>Yes, I think you got this perfectly correct.
<br>
<br></blockquote>
<br>I am at a good stage with 1 and 2. In 3, I am still thinking about some
design choices. I have written the function to resolve the network
'path', however I am trying to figure out which one is the most
appropriate way of inserting the forward rule(s) in each vm in the
chain. I feel like no parsing of the rules should be done in net.py
since it would be out of place and not fit well within the rest of the
code. Thus the rules should be provided to net.py already separated and
sorted in some way. My idea as of now is to add a 'qdb_forward_entries'
function, returning a dict of lists for 'internal' and 'external' rules
in firewall.py. It would be the trivial to process the information in
net.py. What do you think about that?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

82
mails/20210629-Re_GSoC Port Forwarding-13756.html Executable file
View File

@ -0,0 +1,82 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>29/06/2021, 03:31</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Mon, Jun 28, 2021 at 10:46:59PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>On 6/23/21 11:11 PM, Marek Marczykowski-Górecki wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>On Wed, Jun 23, 2021 at 04:37:20PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Hello,
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>thank you again for your time and the explanations, as well as the
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>network graph. I have now a better understanding of the overall design
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>and I am moving myself trhough the source code in order to think what to
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>place where.
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>So, in order to translate what we discussed in practice and also check
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>my understanding of the code so far:
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>1) In core-admin-client/qubesadmin/firewall.py firewall.py &gt; The code
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>needs to support the new options for the rule (action=forward
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>frowardtype=&lt;internal/external&gt; srcports=443-443 srchosts=0.0.0.0/0
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>2) In core-admin/qubes/firewall.py -&gt; The code needs to support the same
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>options as the point above
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>3) In core-admin/qubes/vm/mix/net.py -&gt; The most important logic goes
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>here. Here there is the need to resolve the full network chain for
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>external port forwarding. From here it is possible to add the respective
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>rules to the QubesDB of each netvm in he chain and trigger a reload event.
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>4) in core-agent-linux/qubesagent/firewall.py -&gt; Here goes the logic for
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>building the correct syntax for iptables or nft and the actual execution
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>Does it makes sense for you?
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Yes, I think you got this perfectly correct.
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I am at a good stage with 1 and 2. In 3, I am still thinking about some
<span class="moz-txt-citetags">&gt; </span>design choices. I have written the function to resolve the network
<span class="moz-txt-citetags">&gt; </span>'path', however I am trying to figure out which one is the most
<span class="moz-txt-citetags">&gt; </span>appropriate way of inserting the forward rule(s) in each vm in the
<span class="moz-txt-citetags">&gt; </span>chain. I feel like no parsing of the rules should be done in net.py
<span class="moz-txt-citetags">&gt; </span>since it would be out of place and not fit well within the rest of the
<span class="moz-txt-citetags">&gt; </span>code. Thus the rules should be provided to net.py already separated and
<span class="moz-txt-citetags">&gt; </span>sorted in some way. My idea as of now is to add a 'qdb_forward_entries'
<span class="moz-txt-citetags">&gt; </span>function, returning a dict of lists for 'internal' and 'external' rules
<span class="moz-txt-citetags">&gt; </span>in firewall.py. It would be the trivial to process the information in
<span class="moz-txt-citetags">&gt; </span>net.py. What do you think about that?
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, preparing rules in firewall.py sounds like a good idea. A new
function is a good idea too. But note that for 'external' rules you need
to apply them at several places (sys-net, sys-firewall etc). They aren't
necessarily will be the same.
I'd recommend getting an example, and writing down all the rules that
should be applied, in all related VMs (specific iptables/nft commands).
You have mostly done this part already.
This part you can also test manually - really add those rules
manually and check if everything works as it should. This way you ensure
the rule set is sufficient.
Then, write down QubesDB entries that describe them - carefully matching
which information in the rule is built from which information in qdb
entry.
With that information, you know what qdb entries you need to produce for
each VM, and should be easier to design this extra function/functions -
especially, you'll see what input data such function needs and how many
different rules it needs to return.
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

21
mails/20210713-Auto_ Re_ GSoC Port Forwarding-13919.html Executable file
View File

@ -0,0 +1,21 @@
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Auto: 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>Auto: Re: GSoC Port Forwarding</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Mittente: </div><marmarek@invisiblethingslab.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>13/07/2021, 15:56</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@gmx.com></td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
Hi,
I'm out of office until July 25. I'll read your message after coming back.
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

71
mails/20210713-Re_GSoC Port Forwarding-1069.html Executable file
View File

@ -0,0 +1,71 @@
<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>13/07/2021, 15:56</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&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 29/06/2021 03:31, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">Yes, preparing rules in firewall.py sounds like a good idea. A new
<br>function is a good idea too. But note that for 'external' rules you need
<br>to apply them at several places (sys-net, sys-firewall etc). They aren't
<br>necessarily will be the same.
<br>I'd recommend getting an example, and writing down all the rules that
<br>should be applied, in all related VMs (specific iptables/nft commands).
<br>You have mostly done this part already.
<br>This part you can also test manually - really add those rules
<br>manually and check if everything works as it should. This way you ensure
<br>the rule set is sufficient.
<br>
<br>Then, write down QubesDB entries that describe them - carefully matching
<br>which information in the rule is built from which information in qdb
<br>entry.
<br>With that information, you know what qdb entries you need to produce for
<br>each VM, and should be easier to design this extra function/functions -
<br>especially, you'll see what input data such function needs and how many
<br>different rules it needs to return.
<br>
<br></blockquote>
<br>I tried writing a possible implementation to see how it could work and
also to get an initial feedback. Since in the past week I had no access
to my test machine, I just fixed the last things today and seems that
overall the implemented parts are working (up to writing the rules with
the correctly IPs in the appropriate agent databases).
<br>
<br>Here are the repositories <a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes">https://git.lsd.cat/Qubes</a>
<br>
<br>Here is a list of what has yet to be done:
<br>1) Lot of testing and writing tests
<br>2) Any modification to the agent (such as applying the rules)
<br>3) "srchost" parameter support
<br>4) GUI
<br>5) Find a way to display the chain of rules in the qvm-firewall of every
VM involved since as of now it is displayed only in the VM for which the
rule was set
<br>
<br>Here is a list of what should work:
<br>1) Adding and deleting forward rules, both internal and external, via
qvm-firewall. Also basic checks of the consistency of rules and required
options should be in place
<br>2) Display of forward rules via qvm-firewall
<br>3) Persistence and resume of forward rules in firewall.xml
<br>4) Correct distribution of the required rules in the network chain in net.py
<br>
<br>
<br>Overall I tried getting the most possible from already existing code in
order not to change the style and introduce as few changes as possible.
<br>Without having you correct the code step by step, before going forward
with the agent I would like to have a feedback if the coding style seems
consistent enough with yours and especially if the implementation in
net.py of the distributions of the rules matches your expectations.
<br>
<br>My changes are only in core-admin and core-admin-client for now.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

38
mails/20210714-Re_GSoC Port Forwarding-1073.html Executable file
View File

@ -0,0 +1,38 @@
<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>14/07/2021, 12:16</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;, 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 14/07/2021 12:10, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hi,
<br>
<br>I will have a look to your work probably in the afternoon.
<br>
<br></blockquote>Thank you.
<br>
<br><blockquote type=cite style="color: #007cff;">Just a question, any reason for hosting your work elsewhere than on
GitHub? For example, that would be easier for us to review your code
directly on GitHub (adding comments, tracking easily progression etc).
<br></blockquote>
<br>The main reason is that I manage the server, and so I manage the backups
and have control over everything because I like keeping the web
decentralized somehow, but I understand that working on GitHub is
easier. I already have an account so I can move there.
<br>
<br><blockquote type=cite style="color: #007cff;">Also, I've briefly checked, a good practice is to not work on master
branch directly. I encourage you to use a separate branch named as you
want.
<br></blockquote>
<br>I will do a separate branch moving the code to GitHub. Will also merging
all the commits in a single one improve readability for you?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

29
mails/20210714-Re_GSoC Port Forwarding-1076.html Executable file
View File

@ -0,0 +1,29 @@
<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>14/07/2021, 17:30</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;, 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">Hello,
<br>I have forked the latest repositories available on GitHub and I have
manually diffed and inserted all my changes. I have added some more code
that I have not tested yet in order to refactor a couple of things and
add a basic 'srchost' support, but I think that overall the design
choices already discussed with Marek should be clear.
<br>
<br>The code until now is in a single commit, in the "gsoc-port-forwarding"
branch in the affected repositories:
<br>
<br>&nbsp;-
<a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/commit/6f78a5fcf707140a6401c64a8ed9c8a47ce6e3a1">https://github.com/lsd-cat/qubes-core-admin/commit/6f78a5fcf707140a6401c64a8ed9c8a47ce6e3a1</a>
<br>&nbsp;-
<a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin-client/commit/3b02e93cba17303598db0f0ed031793c6f79dec1">https://github.com/lsd-cat/qubes-core-admin-client/commit/3b02e93cba17303598db0f0ed031793c6f79dec1</a>
<br>
<br>Thank you
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

53
mails/20210714-Re_GSoC Port Forwarding-1077.html Executable file
View File

@ -0,0 +1,53 @@
<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>14/07/2021, 18:27</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;, 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 14/07/2021 17:40, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">Giulio,
<br>
<br>Generally looks good. Do you have already some testing and working case?
If yes, can you please provide few steps here (that would be also good
for doc later).
<br>
<br></blockquote>
<br>I've tested again the code that I added during the refactoring and made
a couple of chanegs to make it work. I have not written any test yet,
however at this stage you can test manually with the following commands
in dom0:
<br>
<br>- # qvm-firewall &lt;domain&gt; add action=forward forwardtype=internal
srcports=443-443 dstports=8443-8443 proto=tcp
<br>
<br>This command should add an internal forwarding rule. In pratice, as of
now, the rule should be visible with the correct attributes running
"qvm-firewall &lt;domain&gt;". Furthermore, the added rule should be present
in the <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>var/lib/qubes/appvms<span class="moz-txt-tag">/</span></i>&lt;domain&gt;/firewall.xml file too and be
correctly represented. Lastly, in the untrusted_qdb of &lt;domain&gt;'s netvm
there should be an entry containing the added rule in the forwarding
base dir.
<br>
<br>- # qvm-firewall &lt;domain&gt; add action=forward forwardtype=wxternal
srcports=80-80 dstports=8080-8080 proto=tcp
<br>
<br>This command should produce almost the exact outcome as the first one.
However, in this case, a specific forward rule containing the ip address
of the next hop should be present in the untrusted_qdb of each vm in the
network path until the last vm where netvm is None (and thus is expected
to have some kind of different interface such as eth).
<br>
<br>Clearly, the port forwarding itself cannot be tested until the proper
handling of the relevant rules is added to the core-agent-linux. I am
now working on that and I expect to have something to test more in depth
in about a week.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

82
mails/20210714-Re_GSoC Port Forwarding-13935.html Executable file
View File

@ -0,0 +1,82 @@
<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>14/07/2021, 12:10</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 &lt;giulio@gmx.com&gt;, 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/13/21 à 3:56 PM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hi,
<br>
<br>Il 29/06/2021 03:31, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">Yes, preparing rules in firewall.py sounds like a good idea. A new
<br>function is a good idea too. But note that for 'external' rules you need
<br>to apply them at several places (sys-net, sys-firewall etc). They aren't
<br>necessarily will be the same.
<br>I'd recommend getting an example, and writing down all the rules that
<br>should be applied, in all related VMs (specific iptables/nft commands).
<br>You have mostly done this part already.
<br>This part you can also test manually - really add those rules
<br>manually and check if everything works as it should. This way you ensure
<br>the rule set is sufficient.
<br>
<br>Then, write down QubesDB entries that describe them - carefully matching
<br>which information in the rule is built from which information in qdb
<br>entry.
<br>With that information, you know what qdb entries you need to produce for
<br>each VM, and should be easier to design this extra function/functions -
<br>especially, you'll see what input data such function needs and how many
<br>different rules it needs to return.
<br>
<br></blockquote>
<br>I tried writing a possible implementation to see how it could work and
<br>also to get an initial feedback. Since in the past week I had no access
<br>to my test machine, I just fixed the last things today and seems that
<br>overall the implemented parts are working (up to writing the rules with
<br>the correctly IPs in the appropriate agent databases).
<br>
<br>Here are the repositories <a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes">https://git.lsd.cat/Qubes</a>
<br>
<br>Here is a list of what has yet to be done:
<br>1) Lot of testing and writing tests
<br>2) Any modification to the agent (such as applying the rules)
<br>3) "srchost" parameter support
<br>4) GUI
<br>5) Find a way to display the chain of rules in the qvm-firewall of every
<br>VM involved since as of now it is displayed only in the VM for which the
<br>rule was set
<br>
<br>Here is a list of what should work:
<br>1) Adding and deleting forward rules, both internal and external, via
<br>qvm-firewall. Also basic checks of the consistency of rules and required
<br>options should be in place
<br>2) Display of forward rules via qvm-firewall
<br>3) Persistence and resume of forward rules in firewall.xml
<br>4) Correct distribution of the required rules in the network chain in net.py
<br>
<br>
<br>Overall I tried getting the most possible from already existing code in
<br>order not to change the style and introduce as few changes as possible.
<br>Without having you correct the code step by step, before going forward
<br>with the agent I would like to have a feedback if the coding style seems
<br>consistent enough with yours and especially if the implementation in
<br>net.py of the distributions of the rules matches your expectations.
<br>
<br>My changes are only in core-admin and core-admin-client for now.
<br>
<br>Cheers
<br>Giulio
<br></blockquote>
<br>I will have a look to your work probably in the afternoon.
<br>
<br>Just a question, any reason for hosting your work elsewhere than on GitHub? For example, that would be easier for us to review your code directly on GitHub (adding comments, tracking easily progression etc). Also, I've briefly checked, a good practice is to not work on master branch directly. I encourage you to use a separate branch named as you want.
<br>
<br>Best regards,
<br>Frédéric
<br>
<br></div></body>
</html>
</table></div>

47
mails/20210714-Re_GSoC Port Forwarding-13938.html Executable file
View File

@ -0,0 +1,47 @@
<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>14/07/2021, 14:57</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 &lt;giulio@gmx.com&gt;, 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">Giulio,
<br>
<br>Le 7/14/21 à 12:16 PM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hi,
<br>
<br>Il 14/07/2021 12:10, Frédéric Pierret ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hi,
<br>
<br>I will have a look to your work probably in the afternoon.
<br>
<br></blockquote>Thank you.
<br>
<br><blockquote type=cite style="color: #007cff;">Just a question, any reason for hosting your work elsewhere than on
<br>GitHub? For example, that would be easier for us to review your code
<br>directly on GitHub (adding comments, tracking easily progression etc).
<br></blockquote>
<br>The main reason is that I manage the server, and so I manage the backups
<br>and have control over everything because I like keeping the web
<br>decentralized somehow, but I understand that working on GitHub is
<br>easier. I already have an account so I can move there.
<br>
<br><blockquote type=cite style="color: #007cff;">Also, I've briefly checked, a good practice is to not work on master
<br>branch directly. I encourage you to use a separate branch named as you
<br>want.
<br></blockquote>
<br>I will do a separate branch moving the code to GitHub. Will also merging
<br>all the commits in a single one improve readability for you?
<br></blockquote>
<br>Perfect.
<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>

38
mails/20210714-Re_GSoC Port Forwarding-13946.html Executable file
View File

@ -0,0 +1,38 @@
<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>14/07/2021, 17:40</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 &lt;giulio@gmx.com&gt;, 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">Giulio,
<br>
<br>Le 7/14/21 à 5:30 PM, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>I have forked the latest repositories available on GitHub and I have
<br>manually diffed and inserted all my changes. I have added some more code
<br>that I have not tested yet in order to refactor a couple of things and
<br>add a basic 'srchost' support, but I think that overall the design
<br>choices already discussed with Marek should be clear.
<br>
<br>The code until now is in a single commit, in the "gsoc-port-forwarding"
<br>branch in the affected repositories:
<br>
<br>&nbsp; -
<br><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/commit/6f78a5fcf707140a6401c64a8ed9c8a47ce6e3a1">https://github.com/lsd-cat/qubes-core-admin/commit/6f78a5fcf707140a6401c64a8ed9c8a47ce6e3a1</a>
<br>&nbsp; -
<br><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin-client/commit/3b02e93cba17303598db0f0ed031793c6f79dec1">https://github.com/lsd-cat/qubes-core-admin-client/commit/3b02e93cba17303598db0f0ed031793c6f79dec1</a>
<br>
<br>Thank you
<br>Cheers
<br>Giulio
<br></blockquote>
<br>Generally looks good. Do you have already some testing and working case? If yes, can you please provide few steps here (that would be also good for doc later).
<br>
<br>Best,
<br>Frédéric
<br>
<br></div></body>
</html>
</table></div>

76
mails/20210717-Re_GSoC Port Forwarding-1086.html Executable file
View File

@ -0,0 +1,76 @@
<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, 17:31</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;, 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>thank you for the positive feedback, I really appreciate it.
<br>I spent the past couple of days digging into the "rules distribution"
mechanism in the various QubesDB. It really took some time to find a
better way to handle and separate the rules for each domain at every
'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
the untrusted qdb of each netvm. This is for easier cleaning and
reloading, and can be used in the future when displaying the forwarding
chain at each step like we were discussing with Marek in the first
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)
&lt;-&gt; sys-vpn (10.137.0.13) &lt;-&gt; sys-tor (10.137.0.14) &lt;-&gt; personal
(10.137.0.10)
<br>
<br>And the following rule:
<br># qvm-firewall personal add action=forward forwardtype=external
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
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
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
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
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
dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>Although this mechanism seems complex, I was not able to think of a
simpler solution. Furthermore I think it is important to know which
appvm is requesting the forwarding at every step, both for debugging and
auditing purposes. Lastly, the next hop ip address has to be determined
automatically anyway and writtem somewhere so there it is.
<br>
<br>I am also thinking about adding a couple of flags to let the nodes know
which one is the first and which one is the last since especially the
last needs additional rules for the external forwarding.
<br>
<br>One more thing, maybe between internal hops it makes sense to randomize
the forwarded ports? This way we can prevent forwarding from different
appvm which shares the same network path or even just one hop from
overlapping, at least internally. Does it makes sense for you?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

45
mails/20210717-Re_GSoC Port Forwarding-1087.html Executable file
View File

@ -0,0 +1,45 @@
<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>

89
mails/20210717-Re_GSoC Port Forwarding-14008.html Executable file
View File

@ -0,0 +1,89 @@
<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>

28
mails/20210801-Re_GSoC Port Forwarding-1100.html Executable file
View File

@ -0,0 +1,28 @@
<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>01/08/2021, 23:50</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>I am still working on the implementation of the rules in the
core-agent-linux package. I have a couple of additional questions:
<br>
<br>1) Currently, I fail to understand and the inner workings the purpose of
the 'connected_ips' part. Could you give me an overall idea of it or any
useful additional details that you think may help me understand?
<br>
<br>2) Since, as we talked in the previous emails, the last node needs an
additional rule in order to forward the port from the external interface
I am wondering how the correct interface is to be determined. I would
automatically choose the device on which there is the route with the
default gateway/destination. But, is it a good idea? Or would be better
to let the user choose?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

48
mails/20210805-Re_GSoC Port Forwarding-14252.html Executable file
View File

@ -0,0 +1,48 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>05/08/2021, 23:31</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
Sorry for late response...
On Sun, Aug 01, 2021 at 11:50:18PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hi,
<span class="moz-txt-citetags">&gt; </span>I am still working on the implementation of the rules in the
<span class="moz-txt-citetags">&gt; </span>core-agent-linux package. I have a couple of additional questions:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>1) Currently, I fail to understand and the inner workings the purpose of
<span class="moz-txt-citetags">&gt; </span>the 'connected_ips' part. Could you give me an overall idea of it or any
<span class="moz-txt-citetags">&gt; </span>useful additional details that you think may help me understand?
</pre></blockquote><pre wrap class="moz-quote-pre">
This is to inform what IPs belong to some VM, even powered off. This
way, firewall can prevent someone spoofing IP of a not running VM
(because it knows that IP cannot come from anywhere else).
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>2) Since, as we talked in the previous emails, the last node needs an
<span class="moz-txt-citetags">&gt; </span>additional rule in order to forward the port from the external interface
<span class="moz-txt-citetags">&gt; </span>I am wondering how the correct interface is to be determined. I would
<span class="moz-txt-citetags">&gt; </span>automatically choose the device on which there is the route with the
<span class="moz-txt-citetags">&gt; </span>default gateway/destination. But, is it a good idea? Or would be better
<span class="moz-txt-citetags">&gt; </span>to let the user choose?
</pre></blockquote><pre wrap class="moz-quote-pre">
This is a very good question. I think the most user-friendly thing to
do, is to include all the external interfaces (network manager will
add several default gateways, just with different priorities). Maybe
later it can be made configurable, but I wouldn't worry about it right
now.
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

48
mails/20210814-Re_GSoC Port Forwarding-1106.html Executable file
View File

@ -0,0 +1,48 @@
<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>14/08/2021, 18:33</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>Sorry for the late reply.
<br>While everything cli related is almost ready, I am having some issues on
the actual implementation of the iptables/nft rules. I see that in the
current state, it seems like Qubes is using both as also stated in [1].
<br>However, in the core-agent-linux source code, if the 'nft' binary is
available&nbsp; that is the only one that gets invoked. Furthermore, there
are differences on the iptables backend depending on templates as
reported in [2].
<br>I am a bit stuck in understanding which rule to put where in order to
have consistency across templates and between iptables/nft, also because
if I blindly implement the rules suggested in [1] they will not actually
work since most of the time iptables is not invoked at all.
<br>I also checked [3], however it is very similar to the instructions in
[1] which leads to the same problems.
<br>Are we able to write working nft forwarding rules without invoking
iptables at all? If yes, could you heml me determine which ones?
<br>
<br>You can see in [4] how I organized the forwarding mechanism. All the
necessary information, as well as ipv4/ipv6 support should already be in
the 'prepare_forward_rules' function meaning that only the actual
building syntax is left.
<br>
<br>For simplicity you can look at the other changes at [5] and at [6].
<br>
<br>Cheers
<br>Giulio
<br>
<br>
<br>[1] - <a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
<br>[2] - <a class="moz-txt-link-freetext" href="https://github.com/QubesOS/qubes-issues/issues/5031">https://github.com/QubesOS/qubes-issues/issues/5031</a>
<br>[3] - <a class="moz-txt-link-freetext" href="https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248">https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248</a>
<br>[4] -
<a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-agent-linux/compare/f24ca2c..3e944af">https://github.com/lsd-cat/qubes-core-agent-linux/compare/f24ca2c..3e944af</a>
<br>[5] - <a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/compare/6a1570b..6e3e250">https://github.com/lsd-cat/qubes-core-admin/compare/6a1570b..6e3e250</a>
<br>[6] -
<a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin-client/compare/1a2ce72..a17853b">https://github.com/lsd-cat/qubes-core-admin-client/compare/1a2ce72..a17853b</a>
<br></div></body>
</html>
</table></div>

92
mails/20210814-Re_GSoC Port Forwarding-14347.html Executable file
View File

@ -0,0 +1,92 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>14/08/2021, 23:43</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Sat, Aug 14, 2021 at 06:33:18PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>Sorry for the late reply.
<span class="moz-txt-citetags">&gt; </span>While everything cli related is almost ready, I am having some issues on
<span class="moz-txt-citetags">&gt; </span>the actual implementation of the iptables/nft rules. I see that in the
<span class="moz-txt-citetags">&gt; </span>current state, it seems like Qubes is using both as also stated in [1].
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, there are two backends, depending on nft availability. This is
mostly because older distros (Debian 8...) did not have nft at all.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>However, in the core-agent-linux source code, if the 'nft' binary is
<span class="moz-txt-citetags">&gt; </span>available that is the only one that gets invoked. Furthermore, there
<span class="moz-txt-citetags">&gt; </span>are differences on the iptables backend depending on templates as
<span class="moz-txt-citetags">&gt; </span>reported in [2].
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, and since basically all the distributions have nft now, iptables
backend may be soon removed. I don't think we have any case where
iptables backend is used in practice in Qubes 4.1. RPM package has
strict dependency on nft, and Debian package has it as Suggests only,
but it is in practice installed.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>I am a bit stuck in understanding which rule to put where in order to
<span class="moz-txt-citetags">&gt; </span>have consistency across templates and between iptables/nft, also because
<span class="moz-txt-citetags">&gt; </span>if I blindly implement the rules suggested in [1] they will not actually
<span class="moz-txt-citetags">&gt; </span>work since most of the time iptables is not invoked at all.
</pre></blockquote><pre wrap class="moz-quote-pre">
Indeed adding rules to the IptablesWorker class will make no effect if
nft is in use.
Theoretically, iptables rules and nft rules can coexist, but we should
really focus on nft with new features.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>I also checked [3], however it is very similar to the instructions in
<span class="moz-txt-citetags">&gt; </span>[1] which leads to the same problems.
<span class="moz-txt-citetags">&gt; </span>Are we able to write working nft forwarding rules without invoking
<span class="moz-txt-citetags">&gt; </span>iptables at all? If yes, could you heml me determine which ones?
</pre></blockquote><pre wrap class="moz-quote-pre">
As for the nft syntax, I think iptables-translate tool can help you
(part of the iptables-nft package).
See <a class="moz-txt-link-freetext" href="https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables">https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables</a>
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>You can see in [4] how I organized the forwarding mechanism. All the
<span class="moz-txt-citetags">&gt; </span>necessary information, as well as ipv4/ipv6 support should already be in
<span class="moz-txt-citetags">&gt; </span>the 'prepare_forward_rules' function meaning that only the actual
<span class="moz-txt-citetags">&gt; </span>building syntax is left.
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, this layout looks ok.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>For simplicity you can look at the other changes at [5] and at [6].
</pre></blockquote><pre wrap class="moz-quote-pre">
This too looks fine (although I haven't don't detailed review).
In both cases, the code will need some tests of course.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>[1] - <a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
<span class="moz-txt-citetags">&gt; </span>[2] - <a class="moz-txt-link-freetext" href="https://github.com/QubesOS/qubes-issues/issues/5031">https://github.com/QubesOS/qubes-issues/issues/5031</a>
<span class="moz-txt-citetags">&gt; </span>[3] - <a class="moz-txt-link-freetext" href="https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248">https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248</a>
<span class="moz-txt-citetags">&gt; </span>[4] -
<span class="moz-txt-citetags">&gt; </span><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-agent-linux/compare/f24ca2c..3e944af">https://github.com/lsd-cat/qubes-core-agent-linux/compare/f24ca2c..3e944af</a>
<span class="moz-txt-citetags">&gt; </span>[5] - <a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/compare/6a1570b..6e3e250">https://github.com/lsd-cat/qubes-core-admin/compare/6a1570b..6e3e250</a>
<span class="moz-txt-citetags">&gt; </span>[6] -
<span class="moz-txt-citetags">&gt; </span><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin-client/compare/1a2ce72..a17853b">https://github.com/lsd-cat/qubes-core-admin-client/compare/1a2ce72..a17853b</a>
</pre></blockquote><pre wrap class="moz-quote-pre">
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

111
mails/20210815-Re_GSoC Port Forwarding-1108.html Executable file
View File

@ -0,0 +1,111 @@
<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>15/08/2021, 17:35</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>Thank you for you fast reply.
<br>
<br>Il 14/08/2021 23:43, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">
<br>As for the nft syntax, I think iptables-translate tool can help you
<br>(part of the iptables-nft package).
<br>See <a class="moz-txt-link-freetext" href="https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables">https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables</a>
<br>
<br><blockquote type=cite style="color: #007cff;">You can see in [4] how I organized the forwarding mechanism. All the
<br>necessary information, as well as ipv4/ipv6 support should already be in
<br>the 'prepare_forward_rules' function meaning that only the actual
<br>building syntax is left.
<br></blockquote>
<br></blockquote>
<br>I have tried to write the external nft rules as well the extarnal ones,
with the exception of the destination domain.
<br>
<br>Assume the following setup:
<br>sys-net - 10.137.0.5 (ens6 phy with 192.168.10.20)
<br>sys-firewall - 10.137.0.6
<br>personal - 10.137.0.7
<br>
<br>All of them are running fedora-32.
<br>
<br>And assume the following rule added via qvm-firewall:
<br># qvm-firewall personal add action=forward forwardtype=external
scrports=22-22 proto=tcp dstports=2222-2222 srchost=192.168.10.0/24
<br>.
<br>First, a table for the forwarding rules is created:
<br>
<br>flush chain {family} qubes-firewall-forward prerouting
<br>flush chain {family} qubes-firewall-forward postrouting
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain postrouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type nat hook postrouting priority srcnat; policy accept;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; masquerade
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type nat hook prerouting priority dstnat; policy accept;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<br>}
<br>
<br>Then, if the qube is marked as 'last', meaning that it is the external
qube with the physical interface the following rules are added:
<br>
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "ens6" {family} saddr 192.168.10.0/24 tcp dport {{ 22 }}
dnat to 10.137.0.6:2222
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>table {family} qubes-firewall {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} daddr 10.137.0.6 tcp dport 2222 ct state
new counter accept
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>And that is all for sys-net.
<br>
<br>In sys-firewall, since it is an 'internal' qube, the following rules are
added instead:
<br>
<br>table {family} qubes-firewall-forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain prerouting {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} saddr 120.137.0.5 tcp dport {{ 2222 }}
dnat to 10.137.0.7:2222
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>table {family} qubes-firewall {
<br>&nbsp;&nbsp;&nbsp;&nbsp;chain forward {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; meta iifname "eth0" {family} daddr 10.137.0.7 tcp dport 2222 ct state
new counter accept
<br>&nbsp;&nbsp;&nbsp;&nbsp;}
<br>}
<br>
<br>Lastly, the appropriate rules allowing incoming traffic on the selected
port from the previous hop should be added directly yo the 'personal'
domain. However I see that there the nft ruleset is empty, while
iptables seems indeed to be in use. I guess that those rules are the
ones specified in qubes-core-agent-linux/network/iptables, however I am
wondering how we should proceed on this one?
<br>
<br>Also are you able to spot errors or something missing in the
aforedescribed rule flow? When testing I can see the incoming connection
on port 22 of the physical interface of sys-net, but then I am losing
track of the connection after that...
<br>
<br>
<br><blockquote type=cite style="color: #007cff;">In both cases, the code will need some tests of course.
<br>
<br></blockquote>
<br>As soon as everything seems to work with my manual test, I will start
progressively writing the automated tests.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

148
mails/20210817-Re_GSoC Port Forwarding-14371.html Executable file
View File

@ -0,0 +1,148 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>17/08/2021, 01:50</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Sun, Aug 15, 2021 at 05:35:37PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>Thank you for you fast reply.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Il 14/08/2021 23:43, Marek Marczykowski-Górecki ha scritto:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>As for the nft syntax, I think iptables-translate tool can help you
<span class="moz-txt-citetags">&gt; &gt; </span>(part of the iptables-nft package).
<span class="moz-txt-citetags">&gt; &gt; </span>See <a class="moz-txt-link-freetext" href="https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables">https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables</a>
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>You can see in [4] how I organized the forwarding mechanism. All the
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>necessary information, as well as ipv4/ipv6 support should already be in
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>the 'prepare_forward_rules' function meaning that only the actual
<span class="moz-txt-citetags">&gt; &gt; &gt; </span>building syntax is left.
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I have tried to write the external nft rules as well the extarnal ones,
<span class="moz-txt-citetags">&gt; </span>with the exception of the destination domain.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Assume the following setup:
<span class="moz-txt-citetags">&gt; </span>sys-net - 10.137.0.5 (ens6 phy with 192.168.10.20)
<span class="moz-txt-citetags">&gt; </span>sys-firewall - 10.137.0.6
<span class="moz-txt-citetags">&gt; </span>personal - 10.137.0.7
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>All of them are running fedora-32.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>And assume the following rule added via qvm-firewall:
<span class="moz-txt-citetags">&gt; </span># qvm-firewall personal add action=forward forwardtype=external
<span class="moz-txt-citetags">&gt; </span>scrports=22-22 proto=tcp dstports=2222-2222 srchost=192.168.10.0/24
<span class="moz-txt-citetags">&gt; </span>.
<span class="moz-txt-citetags">&gt; </span>First, a table for the forwarding rules is created:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>flush chain {family} qubes-firewall-forward prerouting
<span class="moz-txt-citetags">&gt; </span>flush chain {family} qubes-firewall-forward postrouting
<span class="moz-txt-citetags">&gt; </span>table {family} qubes-firewall-forward {
<span class="moz-txt-citetags">&gt; </span> chain postrouting {
<span class="moz-txt-citetags">&gt; </span> type nat hook postrouting priority srcnat; policy accept;
<span class="moz-txt-citetags">&gt; </span> masquerade
</pre></blockquote><pre wrap class="moz-quote-pre">
I think this is too broad - this will hide the source address of all
incoming connections - something that shouldn't be needed.
masquerade is necessary for outgoing traffic only, but it's there
already in default setup (via iptables...)
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span> chain prerouting {
<span class="moz-txt-citetags">&gt; </span> type nat hook prerouting priority dstnat; policy accept;
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span>}
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Then, if the qube is marked as 'last', meaning that it is the external
<span class="moz-txt-citetags">&gt; </span>qube with the physical interface the following rules are added:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>table {family} qubes-firewall-forward {
<span class="moz-txt-citetags">&gt; </span> chain prerouting {
<span class="moz-txt-citetags">&gt; </span> meta iifname "ens6" {family} saddr 192.168.10.0/24 tcp dport {{ 22 }}
<span class="moz-txt-citetags">&gt; </span>dnat to 10.137.0.6:2222
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span>}
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>table {family} qubes-firewall {
<span class="moz-txt-citetags">&gt; </span> chain forward {
<span class="moz-txt-citetags">&gt; </span> meta iifname "eth0" {family} daddr 10.137.0.6 tcp dport 2222 ct state
<span class="moz-txt-citetags">&gt; </span>new counter accept
</pre></blockquote><pre wrap class="moz-quote-pre">
iifname "eth0" ? Should be rather ens6.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span>}
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>And that is all for sys-net.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>In sys-firewall, since it is an 'internal' qube, the following rules are
<span class="moz-txt-citetags">&gt; </span>added instead:
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>table {family} qubes-firewall-forward {
<span class="moz-txt-citetags">&gt; </span> chain prerouting {
<span class="moz-txt-citetags">&gt; </span> meta iifname "eth0" {family} saddr 120.137.0.5 tcp dport {{ 2222 }}
<span class="moz-txt-citetags">&gt; </span>dnat to 10.137.0.7:2222
</pre></blockquote><pre wrap class="moz-quote-pre">
And here, if there wouldn't be masquerade for everything, you could keep
the original source addr (192.168.10.0/24)
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span>}
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>table {family} qubes-firewall {
<span class="moz-txt-citetags">&gt; </span> chain forward {
<span class="moz-txt-citetags">&gt; </span> meta iifname "eth0" {family} daddr 10.137.0.7 tcp dport 2222 ct state
<span class="moz-txt-citetags">&gt; </span>new counter accept
<span class="moz-txt-citetags">&gt; </span> }
<span class="moz-txt-citetags">&gt; </span>}
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Lastly, the appropriate rules allowing incoming traffic on the selected
<span class="moz-txt-citetags">&gt; </span>port from the previous hop should be added directly yo the 'personal'
<span class="moz-txt-citetags">&gt; </span>domain. However I see that there the nft ruleset is empty, while
<span class="moz-txt-citetags">&gt; </span>iptables seems indeed to be in use. I guess that those rules are the
<span class="moz-txt-citetags">&gt; </span>ones specified in qubes-core-agent-linux/network/iptables, however I am
<span class="moz-txt-citetags">&gt; </span>wondering how we should proceed on this one?
</pre></blockquote><pre wrap class="moz-quote-pre">
Ok, this indeed is an issue with mixed iptables / nft usage. For the
purpose of this project, since there isn't much time left, you can
simply stop 'iptables' service in the 'personal' VM - and document
this as a manual step needed. This will become unnecessary when iptables
rules will be migrated to nft.
But there is also another issue: the qubes-firewall daemon is currently
not started if a VM doesn't provide network. So, it isn't started in
'personal' VM here.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Also are you able to spot errors or something missing in the
<span class="moz-txt-citetags">&gt; </span>aforedescribed rule flow? When testing I can see the incoming connection
<span class="moz-txt-citetags">&gt; </span>on port 22 of the physical interface of sys-net, but then I am losing
<span class="moz-txt-citetags">&gt; </span>track of the connection after that...
</pre></blockquote><pre wrap class="moz-quote-pre">
See above - the interface name. You may also like to see this:
<a class="moz-txt-link-freetext" href="https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing">https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing</a>
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

33
mails/20210820-Re_GSoC Port Forwarding-1111.html Executable file
View File

@ -0,0 +1,33 @@
<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>20/08/2021, 03:20</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hi,
<br>I have made a lot of changes in the core-agent-linux code in order to
fix minor bugs which emerged during manual testing as well as improve
the overall logic robustness.
<br>Unfortunately, I am still having some troubles in debugging why the
incoming packes in sys-net are not reaching the next hop (sys-firewall,
10.137.0.6). Tcpdump and nft trace monitor are totally silent in
sys-firewall, which I guess confirms the 0 counter as shown in the
"rules" screenshot (which is of sys-net). Tracing the packets seems to
show a succesful opeartion:
<br>1) The incoming packet is accepted
<br>2) The packet is forwarded to the vif72.0 interface succesfully
<br>
<br>The trace is the result of the "ssh <a class="moz-txt-link-abbreviated" href="mailto:test@192.168.137.128">test@192.168.137.128</a>" command, which
is the ip of ens6 in sys-net
<br>
<br>I will continue to try to debug the problem tomorrow, but still I am not
really sure what to check more...
<br>
<br>
<br>Cheers
<br>Giulio
<br></div><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages-1/0.jpg"></DIV><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages-1/1.jpg"></DIV><br><hr><br><div style="font-size:12px;color:black;"><img src="data:image/gif;base64,R0lGODdhDwAPAOMAAP///zEwYmJlzQAAAPr6+vv7+/7+/vb29pyZ//39/YOBg////////////////////ywAAAAADwAPAAAESRDISUG4lQYr+s5bIEwDUWictA2GdBjhaAGDrKZzjYq3PgUw2co24+VGLYAAAesRLQklxoeiUDUI0qSj6EoH4Iuoq6B0PQJyJQIAOw==">
<ul><li><a href="Attachments-1/trace.JPG">Attachments-1/trace.JPG</li></a><li><a href="Attachments-1/rules.JPG">Attachments-1/rules.JPG</li></a></ul></div><div class='' ></div></body>
</html>

21
mails/20210821-Re_GSoC Port Forwarding-1112.html Executable file
View File

@ -0,0 +1,21 @@
<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>21/08/2021, 00:08</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hi,
<br>as an addendum to the previous email, the problema was the fact that the
first rule to match in the qubes-firewall table, forward chain was:
<br>iifname !="*vif" accept
<br>By moving that to the end of the chain, the attached one is the new
trace which makes a lot more sense and increase the counters.
<br>However, I still cannot see any traffic reaching the next hop.
<br>
<br>Cheers
<br>Giulio
<br></div><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages-2/0.jpg"></DIV><br><hr><br><div style="font-size:12px;color:black;"><img src="data:image/gif;base64,R0lGODdhDwAPAOMAAP///zEwYmJlzQAAAPr6+vv7+/7+/vb29pyZ//39/YOBg////////////////////ywAAAAADwAPAAAESRDISUG4lQYr+s5bIEwDUWictA2GdBjhaAGDrKZzjYq3PgUw2co24+VGLYAAAesRLQklxoeiUDUI0qSj6EoH4Iuoq6B0PQJyJQIAOw==">
<ul><li><a href="Attachments-2/trace.JPG">Attachments-2/trace.JPG</li></a></ul></div><div class='' ></div></body>
</html>

32
mails/20210822-Re_GSoC Port Forwarding-14442.html Executable file
View File

@ -0,0 +1,32 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/08/2021, 00:30</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Sat, Aug 21, 2021 at 12:08:55AM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hi,
<span class="moz-txt-citetags">&gt; </span>as an addendum to the previous email, the problema was the fact that the
<span class="moz-txt-citetags">&gt; </span>first rule to match in the qubes-firewall table, forward chain was:
<span class="moz-txt-citetags">&gt; </span>iifname !="*vif" accept
<span class="moz-txt-citetags">&gt; </span>By moving that to the end of the chain, the attached one is the new
<span class="moz-txt-citetags">&gt; </span>trace which makes a lot more sense and increase the counters.
<span class="moz-txt-citetags">&gt; </span>However, I still cannot see any traffic reaching the next hop.
</pre></blockquote><pre wrap class="moz-quote-pre">
Check if that isn't iptables blocking it. By default it does block new
connections coming from outside. I initially thought it would interfere
only at the final hop, but maybe at an earlier too...
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

31
mails/20210902-Re_GSoC Port Forwarding-1115.html Executable file
View File

@ -0,0 +1,31 @@
<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>02/09/2021, 13:26</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>Thank you both for the support during the previous phase and your
patience. Thank you also for the positive evaluation, I really
appreciate it.
<br>
<br>Although the project is not production ready, I would like to continue
working on it and eventually get it merged if it reaches a stable and
fully working condition.
<br>
<br>I am little bit offline now because I just moved to a new city to pursue
my master degree. However, I will continue to work on it again as soon
as I can.
<br>
<br>Since we are now out of the GSoC scope I would like to introduce the
project to the community so I can eventually get feedbacks and support,
especially for the network layer and rules. Is it ok if I open a GitHub
issue and maybe a discussion on the forum?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>

49
mails/20210902-Re_GSoC Port Forwarding-14614.html Executable file
View File

@ -0,0 +1,49 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>02/09/2021, 13:59</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Thu, Sep 02, 2021 at 01:26:34PM +0200, Giulio wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>Thank you both for the support during the previous phase and your
<span class="moz-txt-citetags">&gt; </span>patience. Thank you also for the positive evaluation, I really
<span class="moz-txt-citetags">&gt; </span>appreciate it.
</pre></blockquote><pre wrap class="moz-quote-pre">
As said in the evaluation form - thanks for working on this, and
persistence in solving challenges!
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Although the project is not production ready, I would like to continue
<span class="moz-txt-citetags">&gt; </span>working on it and eventually get it merged if it reaches a stable and
<span class="moz-txt-citetags">&gt; </span>fully working condition.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I am little bit offline now because I just moved to a new city to pursue
<span class="moz-txt-citetags">&gt; </span>my master degree. However, I will continue to work on it again as soon
<span class="moz-txt-citetags">&gt; </span>as I can.
</pre></blockquote><pre wrap class="moz-quote-pre">
When you have time, maybe open a (draft) pull requests to relevant
repositories? This would ease collecting feedback, I think.
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Since we are now out of the GSoC scope I would like to introduce the
<span class="moz-txt-citetags">&gt; </span>project to the community so I can eventually get feedbacks and support,
<span class="moz-txt-citetags">&gt; </span>especially for the network layer and rules. Is it ok if I open a GitHub
<span class="moz-txt-citetags">&gt; </span>issue and maybe a discussion on the forum?
</pre></blockquote><pre wrap class="moz-quote-pre">
Yes, definitely!
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

36
mails/20211019-Re_GSoC Port Forwarding-1134.html Executable file
View File

@ -0,0 +1,36 @@
<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>19/10/2021, 14:48</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 &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>
<br>Il 02/09/2021 13:59, Marek Marczykowski-Górecki ha scritto:
<br>&gt; On Thu, Sep 02, 2021 at 01:26:34PM +0200, Giulio wrote:
<br>&gt;
<br>&gt; When you have time, maybe open a (draft) pull requests to relevant
<br>&gt; repositories? This would ease collecting feedback, I think.
<br>&gt;
<br>&gt;&gt; Since we are now out of the GSoC scope I would like to introduce the
<br>&gt;&gt; project to the community so I can eventually get feedbacks and support,
<br>&gt;&gt; especially for the network layer and rules. Is it ok if I open a GitHub
<br>&gt;&gt; issue and maybe a discussion on the forum?
<br>&gt;
<br>&gt; Yes, definitely!
<br>&gt;
<br>
<br>I am now drafting the pull requests and the message to send to the
community. May I publish our correspondance? I feel like it could be a
useful addendum to the documentation and help people understand the
design choices and the development process. Otherwise if you prefer to
keep them private no problem at all <span class="moz-smiley-s1" title=":)"><span>:)</span></span>
<br>
<br>Cheers
<br>Giulio
<br>
<br></div></body>
</html>
</table></div>

44
mails/20211019-Re_GSoC Port Forwarding-15265.html Executable file
View File

@ -0,0 +1,44 @@
<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>19/10/2021, 14:59</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 &lt;giulio@gmx.com&gt;, 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">Hello,
<br>
<br>Le 10/19/21 à 14:48, Giulio a écrit :
<br><blockquote type=cite style="color: #007cff;">Hello,
<br>
<br>Il 02/09/2021 13:59, Marek Marczykowski-Górecki ha scritto:
<br>&nbsp;&gt; On Thu, Sep 02, 2021 at 01:26:34PM +0200, Giulio wrote:
<br>&nbsp;&gt;
<br>&nbsp;&gt; When you have time, maybe open a (draft) pull requests to relevant
<br>&nbsp;&gt; repositories? This would ease collecting feedback, I think.
<br>&nbsp;&gt;
<br>&nbsp;&gt;&gt; Since we are now out of the GSoC scope I would like to introduce the
<br>&nbsp;&gt;&gt; project to the community so I can eventually get feedbacks and support,
<br>&nbsp;&gt;&gt; especially for the network layer and rules. Is it ok if I open a GitHub
<br>&nbsp;&gt;&gt; issue and maybe a discussion on the forum?
<br>&nbsp;&gt;
<br>&nbsp;&gt; Yes, definitely!
<br>&nbsp;&gt;
<br>
<br>I am now drafting the pull requests and the message to send to the
<br>community. May I publish our correspondance? I feel like it could be a
<br>useful addendum to the documentation and help people understand the
<br>design choices and the development process. Otherwise if you prefer to
<br>keep them private no problem at all <span class="moz-smiley-s1" title=":)"><span>:)</span></span>
<br>
<br>Cheers
<br>Giulio
<br>
<br></blockquote>
<br>Thank you for that. I'm ok with publishing private correspondence.
<br>
<br>Best,
<br>Frédéric
<br></div></body>
</html>
</table></div>

54
mails/20211019-Re_GSoC Port Forwarding-15267.html Executable file
View File

@ -0,0 +1,54 @@
<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>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>19/10/2021, 15:10</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>Giulio &lt;giulio@gmx.com&gt;</td></tr></table><br>
<div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
On Tue, Oct 19, 2021 at 02:59:45PM +0200, Frédéric Pierret wrote:
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>Hello,
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Le 10/19/21 à 14:48, Giulio a écrit :
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; &gt; </span>Hello,
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Il 02/09/2021 13:59, Marek Marczykowski-Górecki ha scritto:
<span class="moz-txt-citetags">&gt; &gt; </span> &gt; On Thu, Sep 02, 2021 at 01:26:34PM +0200, Giulio wrote:
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;
<span class="moz-txt-citetags">&gt; &gt; </span> &gt; When you have time, maybe open a (draft) pull requests to relevant
<span class="moz-txt-citetags">&gt; &gt; </span> &gt; repositories? This would ease collecting feedback, I think.
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;&gt; Since we are now out of the GSoC scope I would like to introduce the
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;&gt; project to the community so I can eventually get feedbacks and support,
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;&gt; especially for the network layer and rules. Is it ok if I open a GitHub
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;&gt; issue and maybe a discussion on the forum?
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;
<span class="moz-txt-citetags">&gt; &gt; </span> &gt; Yes, definitely!
<span class="moz-txt-citetags">&gt; &gt; </span> &gt;
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>I am now drafting the pull requests and the message to send to the
<span class="moz-txt-citetags">&gt; &gt; </span>community. May I publish our correspondance? I feel like it could be a
<span class="moz-txt-citetags">&gt; &gt; </span>useful addendum to the documentation and help people understand the
<span class="moz-txt-citetags">&gt; &gt; </span>design choices and the development process. Otherwise if you prefer to
<span class="moz-txt-citetags">&gt; &gt; </span>keep them private no problem at all <span class="moz-smiley-s1" title=":)"><span>:)</span></span>
<span class="moz-txt-citetags">&gt; &gt; </span>
<span class="moz-txt-citetags">&gt; &gt; </span>Cheers
<span class="moz-txt-citetags">&gt; &gt; </span>Giulio
<span class="moz-txt-citetags">&gt; &gt; </span>
</pre></blockquote><pre wrap class="moz-quote-pre">
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Thank you for that. I'm ok with publishing private correspondence.
</pre></blockquote><pre wrap class="moz-quote-pre">
Fine with me too <span class="moz-smiley-s1" title=":)"><span>:)</span></span>
<div class="moz-txt-sig">--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
</div></pre></div></body>
</html>
</table></div>

BIN
mails/Attachments-1/rules.JPG Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 96 KiB

BIN
mails/Attachments-1/trace.JPG Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
mails/Attachments-2/trace.JPG Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

BIN
mails/Attachments/network-graph.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 162 KiB

BIN
mails/EmbeddedImages-1/0.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
mails/EmbeddedImages-1/1.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 96 KiB

BIN
mails/EmbeddedImages-2/0.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

BIN
mails/EmbeddedImages/0.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 162 KiB

195
mails/index.html Executable file
View File

@ -0,0 +1,195 @@
<html>
<head>
<style>
table { border-collapse: collapse; }
th { background-color: #e6ffff; }
th, td { padding: 4px; text-align: left; vertical-align: center; }
tr:nth-child(even) { background-color: #f0f0f0; }
tr:nth-child(odd) { background-color: #fff; }
tr>:nth-child(5) { text-align: center; }
</style>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Posta in arrivo</title>
</head>
<body>
<h2>Posta in arrivo (10/19/2021)</h2><table width="99%" border="1" ><tr><th><b>Oggetto</b></th><th><b>Mittente</b></th><th><b>A</b></th><th><b>Data</b></th><th><b>Allegato</b></th></tr>
<tr><td><a href="20210611-GSoC%20Port%20Forwarding-1046.html">GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>6/11/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210611-Re_GSoC%20Port%20Forwarding-13573.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;, Marek Marczykowski-Górec</td>
<td nowrap>6/11/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210620-Re_GSoC%20Port%20Forwarding-1051.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>6/20/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210622-Re_GSoC%20Port%20Forwarding-1052.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>6/22/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210622-Re_GSoC%20Port%20Forwarding-13692.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>6/22/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210622-Re_GSoC%20Port%20Forwarding-1053.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>6/22/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210622-Re_GSoC%20Port%20Forwarding-13697.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>6/22/2021</td>
<td align="center">* </td></tr>
<tr><td><a href="20210623-Re_GSoC%20Port%20Forwarding-1054.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>6/23/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210623-Re_GSoC%20Port%20Forwarding-13708.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>6/23/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210628-Re_GSoC%20Port%20Forwarding-1058.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>6/28/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210629-Re_GSoC%20Port%20Forwarding-13756.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>6/29/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210713-Re_GSoC%20Port%20Forwarding-1069.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>7/13/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210713-Auto_%20Re_%20GSoC%20Port%20Forwarding-13919.html">Auto: Re: GSoC Port Forwarding</a></td>
<td>&lt;marmarek@invisiblethingslab.com&gt;</td>
<td>&lt;giulio@gmx.com&gt;</td>
<td nowrap>7/13/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-13935.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;, Marek Marczykowski-Górec</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-1073.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-13938.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;, Marek Marczykowski-Górec</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-1076.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-13946.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;, Marek Marczykowski-Górec</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210714-Re_GSoC%20Port%20Forwarding-1077.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>7/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210717-Re_GSoC%20Port%20Forwarding-1086.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;,</td>
<td nowrap>7/17/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210717-Re_GSoC%20Port%20Forwarding-14008.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>7/17/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210717-Re_GSoC%20Port%20Forwarding-1087.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td nowrap>7/17/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210801-Re_GSoC%20Port%20Forwarding-1100.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td nowrap>8/01/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210805-Re_GSoC%20Port%20Forwarding-14252.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>8/05/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210814-Re_GSoC%20Port%20Forwarding-1106.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>8/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210814-Re_GSoC%20Port%20Forwarding-14347.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>8/14/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210815-Re_GSoC%20Port%20Forwarding-1108.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>8/15/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210817-Re_GSoC%20Port%20Forwarding-14371.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>8/17/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210820-Re_GSoC%20Port%20Forwarding-1111.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>8/20/2021</td>
<td align="center">* </td></tr>
<tr><td><a href="20210821-Re_GSoC%20Port%20Forwarding-1112.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>8/21/2021</td>
<td align="center">* </td></tr>
<tr><td><a href="20210822-Re_GSoC%20Port%20Forwarding-14442.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>8/22/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210902-Re_GSoC%20Port%20Forwarding-1115.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>9/02/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20210902-Re_GSoC%20Port%20Forwarding-14614.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td nowrap>9/02/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20211019-Re_GSoC%20Port%20Forwarding-1134.html">Re: GSoC Port Forwarding</a></td>
<td>Giulio &lt;giulio@gmx.com&gt;</td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td nowrap>10/19/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20211019-Re_GSoC%20Port%20Forwarding-15265.html">Re: GSoC Port Forwarding</a></td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td>Giulio &lt;giulio@gmx.com&gt;, Marek Marczykowski-Górec</td>
<td nowrap>10/19/2021</td>
<td align="center">&nbsp;</td></tr>
<tr><td><a href="20211019-Re_GSoC%20Port%20Forwarding-15267.html">Re: GSoC Port Forwarding</a></td>
<td>Marek Marczykowski-Górecki &lt;marmarek@invisiblethi</td>
<td>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td>
<td nowrap>10/19/2021</td>
<td align="center">&nbsp;</td></tr></table></body></html>