What is the risks/benefits of setting USB and Net to be the same?

I’m honestly trying to understand the specific case you’re talking about in which the sys-net qube can compromise the devices in sys-usb qube so I’m asking for a details of the configuration/qubes usage that could lead to it.
If you feel that I’m trolling than we can just stop the discussion.

I’ll try one more time and then give up on this B&F.

  1. @fslover looks like he understood what I’m talking about and quoted this topic:
    Which one is more secure: "sys-usb" or "sys-net as sys-usb"?

On that short topic, also another topic is quoted, so I’ll re-qoute it here

That topic is short too. If you read it (which makes me think you didn’t, otherwise you’d ask what is not clear there, not here), it is exactly the situation where you can compromise your sys-usb via sys-net.

  1. You could have your ethernet controller attached to sys-net, while having any other network device (internal or external) attached to USB controller(s). I’m repeating myself for the last time here.
    So you choose to go online via your USB network device online (in parallel with sys-net or alone, it doesn’t matter). So, that scenario would compromise your USB devices too, and what’s more dangerous - controller on which USB network device is attached to, and even more dangerous, all other USB controllers that are attached to the same sys-usb, regardless of the fact that you have separate sys-net and sys-usb.

  2. I can attach some PCI and USB controllers to a sys-net, and other USB controllers to a sys-usb. All USB devices attached to a sys-net will be compromised once sys-net is compromised, regardless of the fact that you have separate sys-net and sys-usb.

So your claim

… is not correct and complete (see 2. and 3.) and could mislead users to a false sense of security, because your claim is correct in only one scenario:

  • user have all network devices and controllers they’re attached to in a sys-net, and devices from those controller(s) aren’t later attached to sys-usb and vice versa, and you’re not attaching any other USB device to that controller residing in a sys-net.

I tried to point this, but it looks like you’re insisting your claim is one and only that is correct, so I’m leaving you there.

From this point on, I’d reply only users that are further interested in explanation, but only if they confirmed they read all the quoted topics, and the posts here, explicitly quoting claims that aren’t clear enough for them.

Moderation note:

By the time one feels the need to write abrasive comments or state own assumptions beyond what people tell of their motivations, it might be time to take a step back. If a topic is not yielding expected outcomes, sometimes giving it some time for other folks to join the conversation goes a long way.

Quick abrasive two-people conversations are less likely to encourage anyone to join, and the forum isn’t an appropriate place to discuss private grievances.

1 Like

Ok, I understand your point now, thank you for the clarification.
I was talking about two default configurations provided by the Qubes OS installer:

I agree that my statement:

Won’t be true for all cases e.g. if user decides to make any changes to the default sys-net/sys-usb configuration created by Qubes OS installer.

E.g. as I stated before:

But you answer:

Confused me and I thought that you meant something else.

If user adds a PCI USB controller from sys-usb to sys-net to use a USB network adapter connected to this USB controller and then attach some other USB devices to the same USB controller this won’t conflict with my statement but the other USB devices connected to the PCI USB controller attached to the sys-net qube will be compromised as well with sys-net compromise so it could worth to mention this.

Also as mentioned in the topic that you linked, there is also a concern that having a PCI network controller in sys-net could lead to a side-channel attack (e.g. DMA attack) and this could lead to the compromise of USB devices in sys-usb as well. But there is a greater concern in this situation, because this attack could lead to a dom0 compromise as well.

Now, that’s an add up and as I see it, now the topic has the most comprehensive overview on the much broader potential issues the subject of this topic actually hides (arises), than it might look at the first glance, especially to the novices.