Hello,
sorry for the late reply.
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.
Here is the summary of the notes I've taken from my understanding in
this week of digging.
Main references:
https://www.qubes-os.org/doc/admin-api/
https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x
https://www.qubes-os.org/doc/firewall/
_core-admin/qubes/firewall.py_
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.
_core-admin-client/qubesadmin/tools/qvm_firewall.py_
Class for the qvm-firewall cli tool. It is able to view, add, delete and
reload firewall rules.
_core-admin-client/qubesadmin/firewall.py_
The file responsible for calling Admin API (qubesd). Currently has its
own rule syntax for setting rules.
_core-agent-linux/qubesagent/firewall.py_
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).
_manager/qubesmanager/firewall.py_
Contains the code for the "Firewall" tab of the "Qube Manager" window.
_manager/ui/qubemanager.ui_
String and properties for the "Qube Manager" UI.
Questions:
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.
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.
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.
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?
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?
Proposed XML Syntax:
<rule>
<properties>
<property name="action">forward</property>
<property name="proto">udp</property>
<property name="dstports">443-8080-5555</property>
</properties>
<rule>
Proposed Admin API Syntax:
action=forward proto=udp dstports=443-8080-5555 [expire=<unix
timestamp>] [comment=random text]
I also plan to document, at least partially, the journey into this.
As a last question, I'm curious what is your setup in order to test
modifications in the aforementioned repos while developing.
Thank you for your time.
Cheers
Giulio
Il 11/06/2021 09:16, Frédéric Pierret ha scritto:
Hello,
Le 6/11/21 à 8:24 AM, Giulio a écrit :
Hello,
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?
Sure.
Cheers,
Giulio
Best,
Frédéric