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 now totally understand your doubts, and I think the simplest solution
> then would be a time/date picker, so if the user is planning anything
> specific he can configure all the set of rules to the same expiration
> timewithout  incurring in the synchronization issues you mentioned.

Yes, that could work, with some easy way to use the same time for
multiple rules (for example default to the last choice).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab