Hi,

Le 7/17/21 à 5:31 PM, Giulio a écrit :

Hi,
thank you for the positive feedback, I really appreciate it.
I spent the past couple of days digging into the "rules distribution"
mechanism in the various QubesDB. It really took some time to find a
better way to handle and separate the rules for each domain at every
'step' of their network path.

https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169

The idea here is that each appvm will have a separate QubesDB folder on
the untrusted qdb of each netvm. This is for easier cleaning and
reloading, and can be used in the future when displaying the forwarding
chain at each step like we were discussing with Marek in the first
emails. A practical example follows.

Assume the following network path:

*internet/lan* <-> sys-net (10.137.0.5) <-> sys-firewall (10.137.0.6)
<-> sys-vpn (10.137.0.13) <-> sys-tor (10.137.0.14) <-> personal
(10.137.0.10)

And the following rule:
# qvm-firewall personal add action=forward forwardtype=external
proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

Here are the QubesDB entries that are automatically added, to be
consumed from the core-agent-linux:

In sys-net:
key = /qubes-firewall-forward/personal/10.137.0.6/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24

In sys-firewall:
key = /qubes-firewall-forward/personal/10.137.0.13/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24

In sys-vpn:
key = /qubes-firewall-forward/personal/10.137.0.14/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24

In sys-tor:
key = /qubes-firewall-forward/personal/10.137.0.10/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24

Although this mechanism seems complex, I was not able to think of a
simpler solution. Furthermore I think it is important to know which
appvm is requesting the forwarding at every step, both for debugging and
auditing purposes. Lastly, the next hop ip address has to be determined
automatically anyway and writtem somewhere so there it is.

I've not an alternative idea yet but, I'm wondering if leaking appvm names in "higher" untrusted appvms is reasonable, especially for confidentiality. Maybe simply use the destination appvm ip, here in your example that would be personal ip. dom0/GuiVM has access to the info so getting appvm name from ip should be simple.

I am also thinking about adding a couple of flags to let the nodes know
which one is the first and which one is the last since especially the
last needs additional rules for the external forwarding.

Here too, I'm not sure adding such info is a good idea for security. What exactly do you have in mind for the last needs additional rules?

One more thing, maybe between internal hops it makes sense to randomize
the forwarded ports? This way we can prevent forwarding from different
appvm which shares the same network path or even just one hop from
overlapping, at least internally. Does it makes sense for you?

Yes that can be some kind of useful hardening or to prevent any conflict indeed.

Cheers
Giulio

Best,
Frédéric