123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138 |
- <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>
|