<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 <frederic.pierret@qubes-os.org>, Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com></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? (<netvm,firewallvm,appvm>). 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><rule>
<br> <properties>
<br> <property name="action">forward</property>
<br> <property name="proto">udp</property>
<br> <property name="dstports">443-8080-5555</property>
<br> </properties>
<br><rule>
<br>
<br>Proposed Admin API Syntax:
<br>action=forward proto=udp dstports=443-8080-5555 [expire=<unix
timestamp>] [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>