138 lines
7.3 KiB
HTML
Executable File
138 lines
7.3 KiB
HTML
Executable File
<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> |