On 6/23/21 11:11 PM, Marek Marczykowski-Górecki wrote:

On Wed, Jun 23, 2021 at 04:37:20PM +0200, Giulio wrote:

Hello,
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.

So, in order to translate what we discussed in practice and also check
my understanding of the code so far:

1) In core-admin-client/qubesadmin/firewall.py firewall.py > The code
needs to support the new options for the rule (action=forward
frowardtype=<internal/external> srcports=443-443 srchosts=0.0.0.0/0
2) In core-admin/qubes/firewall.py -> The code needs to support the same
options as the point above
3) In core-admin/qubes/vm/mix/net.py -> 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.
4) in core-agent-linux/qubesagent/firewall.py -> Here goes the logic for
building the correct syntax for iptables or nft and the actual execution

Does it makes sense for you?

Yes, I think you got this perfectly correct.

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?

Cheers
Giulio