Having a sys-firewall-usb by default might be confusing maybe?
sys-usb being an implicit sys-usb-net is not less confusing 
True. I don’t know how people do network with USB devices, it’s possible to handle it directly in sys-usb, but also pass the device to sys-net 
The suggested sys-net/-firewall/-usb nftables rules are there to block undesired output (i.e. locally generated) traffic, not traffic forwarded from a downstream VM.
True. I don’t know how people do network with USB devices, it’s possible to handle it directly in sys-usb, but also pass the device to sys-net
Sometimes I use USB Wi-Fi dongles which I attach to sys-net, not to sys-usb. No idea what others do and why.
1 Like
The firewall rule is there to block accidental output (i.e. locally generated) traffic, not traffic forwarded from a downstream VM.
Yes. And it all comes down to what accidental means
sys-net and sys-usb are distrusted qubes. The procedure of letting them control their own traffic implies trust.
Quite confusing.
I had edited it to say “undesired output”. Basically I just mean that any general purpose distro in sys-net/-firewall/-usb, composed of a huge amount of off-the-shelf software, will have plenty of odd bits and pieces generating IP traffic for benign purposes and usually that’s fine. Except if the user does not want to emit any non-Tor/VPN traffic. This sort of misconfiguration is hard to address one by one for every individual thing (especially considering that new stuff could be introduced at any moment by upstream package updates). Hence the need for nftables rules as a catch-all.
Of course, a malicious (not just accidentally misconfigured) sys-net etc. can emit whatever it wants through attached network hardware. There’s no way to prevent that inside of Qubes OS.
But even if the nftables rules are not intended as a security mechanism (against attacks), it’s true you would have to trust them as a safety mechanism. So hopefully we can get them just right, correctly ordered during early boot, all of that
Hi!
After reading this discussion, I changed my default Net Qube in the global configuration to sys-whonix. By doing so, the net qube for the default DVM also changed to sys-whonix.
Since then, I’ve been monitoring network traffic for almost a week using Sniffnet installed on sys-net, and there are no longer any clearnet leaks.
I’ve noticed that if I manually run the command sudo dnf update in the terminal of sys-net or sys-firewall, these VMs check for updates on clearnet. However, otherwise, the system checks for updates fine, new updates are coming in, and nothing is going through clearnet.
Correct me if I’m wrong, but my observation is that setting the default net qube to sys-whonix resolves this issue.
This is really great for many reasons. I would give 2 hearts and a solution label if I could.
What about update checks and clockvm traffic from sys-net?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
I’m not sure which IP the ClockVM traffic goes to, so I can’t comment on that. However, I can confirm that all update checks are definitely going through the Tor network. Before setting sys-whonix as the default net qube, I observed Fedora’s update checks on the clearnet. It’s been a week since I changed the default net qube to sys-whonix, and I haven’t seen any clearnet activity since then, even though I’ve received Fedora updates during this period. Since Fedora is the template for sys-net, I assume the update check was done on sys-net too, although I can’t confirm.
Update: After a week, I received clearnet traffic from Fedora today from these three addresses:
My observation was incorrect. Sorry about that… 
1 Like
Of course, a malicious (not just accidentally misconfigured) VM can pass whatever it wants upstream (through its netvm, or through attached network hardware). There’s no way around that.
Yes.
30 posts were split to a new topic: What are the Privacy Implications of NTP Requests (time sync) and how to mitigats them