On Mon, Jun 28, 2021 at 10:46:59PM +0200, Giulio wrote:

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

Yes, preparing rules in firewall.py sounds like a good idea. A new
function is a good idea too. But note that for 'external' rules you need
to apply them at several places (sys-net, sys-firewall etc). They aren't
necessarily will be the same.
I'd recommend getting an example, and writing down all the rules that
should be applied, in all related VMs (specific iptables/nft commands).
You have mostly done this part already.
This part you can also test manually - really add those rules
manually and check if everything works as it should. This way you ensure
the rule set is sufficient.

Then, write down QubesDB entries that describe them - carefully matching
which information in the rule is built from which information in qdb
entry.
With that information, you know what qdb entries you need to produce for
each VM, and should be easier to design this extra function/functions -
especially, you'll see what input data such function needs and how many
different rules it needs to return.

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