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?
Il 22/06/2021 16:04, Marek Marczykowski-Górecki ha scritto:
On Tue, Jun 22, 2021 at 02:28:26PM +0200, Giulio wrote:
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.
Per-rule expire may be tricky to handle at the GUI level, I have no idea
how to make the UI for this not very confusing...
But the comment field is definitely useful to use.
How do you see the same checkbox that actually allows full internet
access with the 5 minutes expiration time, displayed also on the window
for adding a rule?
This may be more relevant to longer times. With times like 5min, just
setting the rules up (if you want more than one of them) may already eat
up significant portion of the expiration time...
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.
Cheers
Giulio