[Contribution] qubes-network-topology

[andrewdavidwong]

Community Dev: @Zrubi
PoC: https://gist.github.com/Zrubi/6229d5400bde987b1aa8da516553b909

---

Several users over the years have requested a feature that allows them to visualize the topography of their VMs in the form of a graph, and some of our users have even developed tools that accomplish these. We should consider selecting and integrating one of these tools into Qubes.

Discussion threads:

• https://groups.google.com/d/topic/qubes-users/EPuXNkSFxdE/discussion
• https://groups.google.com/d/topic/qubes-devel/64-WJIMY18A/discussion

[andrewdavidwong]

@Zrubi, would you be willing to package your contribution following our new package contribution procedure?

[ninavizz]

Commenting to get this on my radar. @andrewdavidwong mind adding the UX tag to this? Seems like a nice add-on feature to a future redesign of Qubes Manager.

[andrewdavidwong]

Commenting to get this on my radar. @andrewdavidwong mind adding the UX tag to this? Seems like a nice add-on feature to a future redesign of Qubes Manager.

Added!

[deeplow]

@ninavizz I also have some thoughts on this.

For example, I've identified it as a trend users misunderstanding the purpose of sys-firewall and they often end up connecting directly to sys-net. A network topology visualizer could add some visual warnings explaining as to why this may not be a good idea if the user doesn't understand the implications.

[ninavizz]

@deeplow sys-net isn't what I connect through?? Good to know! Yeah, only geeks know to connect directly to a firewall, I guess? I like your thinking that it's a good place to provide guidance on how to best configure one's system for safety.

There's a separate issue I'd like to file to also create a new feature to give users insight into their hardware, w/o requiring CLI things. Like, I really need that info to know if I can upgrade my memory, what my storage situation is, and what my monitor support options are. I'll be creating a ticket for that, separately, but this feels like it'd fit perfectly into that.

@marmarek could we pull the 4.1milestone from this? I'd rather not bloat that release with this, tbh. This feels like it'll add too much additional testing into existing 4.1 backlog stuff... and I think users wd rather get the rest of the 4.1 goodness, before waiting on this?

[deeplow]

@deeplow sys-net isn't what I connect through?? Good to know!

Yup. Exactly. I think this is one big security issue due to end-user misconfiguration caused to lack of awareness of the purpose of sys-firewall. As far as I understand it AppVMs should be connected to like this:

Correct:

• sys-net <- sys-firewall <- work
• sys-net <- sys-firewall <- sys-vpn <- work

Incorrect:

• sys-net <- work
• sys-net <-sys-vpn <- work

Otherwise the will be no network firewall isolation between VMs. But I need to do some more reading on this as well.

[Zrubi]

On 12/31/20 12:28 AM, deeplow wrote: @deeplow <https://github.com/deeplow> |sys-net| isn't what I connect through?? Good to know! Yup. Exactly. I think this is one big security issue due to end-user misconfiguration due to lack of awareness of the purpose of |sys-firewall|. As far as I understand it AppVMs should be connected to like this: *Correct:* * |sys-net| <- |sys-firewall| <- |work| * |sys-net| <- |sys-firewall| <- |sys-vpn| <- |work| *Incorrect:* * |sys-net| <- |work| * |sys-net| <-|sys-vpn| <- |work| Otherwise the will be no network firewall isolation between VMs. But I need to do some more reading on this as well.

I would argue with this statement. sys-firewall is just an example. A default firewall VM created by the installer. But you - or maybe just the geeks? :) - can run the same services - including firewall - in any proxy vm. So in practice, you can run the same services in your "sys-vpn" - or whatever you call it. Then there will be NO security degradation, but you just save an extra NAT and an extra VM with all it's resource needs. If you completely skip the firewall, then you are right, one may 'miss' the firewall services. But in practice, you should do it on purpose, with your own reasons.

…

-- Zrubi

[deeplow]

So in practice, you can run the same services in your "sys-vpn" - or whatever you call it. Then there will be NO security degradation, but you just save an extra NAT and an extra VM with all it's resource needs.

Advanced users understand what they are doing and know which warnings they can dismiss. There is no need to protect those users.

The key goal here would be to prevent less technical users from shooting themselves in the foot.

[3hhh]

Alternatives from #6269:

• https://github.com/3hhh/qvm-ls-mermaid
• https://github.com/unman/viewer

[ghost]

Another alternative https://github.com/hexstore/qubes-proxy