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
Thanks for the guide @solene. I have made some improvements. Notably, my version runs before network-pre.target, which prevents any traffic from leaking. I have also structured it such that if something goes wrong with the nftables rules, no uplink will be brought up. There was existing support for doing this with Qubes-managed (virtual) uplinks, but the support for doing this with NetworkManager-managed (physical) interfaces was missing. I’ve now added it. Finally, this allows loopback communication.
My implementation follows @rustybird suggestion from Preventing non-Tor connections - #31 by rustybird
These files should be created in a template VM that is specifically for sys-net/sys-firewall.
/lib/systemd/system/external-output-firewall.service
[Unit]
Description=External output firewall
Before=network-pre.target
# Arbitrary order, but keeps it consistent.
Before=qubes-antispoof.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/nft -f /etc/qubes/external-output-firewall.nft
# So that it never runs more than once.
RemainAfterExit=yes
[Install]
# Qubes does not follow systemd.special man page, where network-pre.target is specified passive. Instead, network-pre
# pulls units in (qubes-antispoof, qubes-iptables) and fails if they fail. This failure is then used to stop
# qubes-network-uplink@eth0.service from activating, which stops eth0 from being brought up (unless NetworkManager is
# managing the interface).
RequiredBy=network-pre.target
/etc/qubes/external-output-firewall.nft
#!/usr/sbin/nft -f
table inet external-output-firewall {
chain output {
type filter hook output priority filter; policy drop;
oifname "lo" accept
}
}
/lib/systemd/system/NetworkManager.service.d/50_user.conf
[Unit]
# Refer to /lib/systemd/system/external-output-firewall.service. NetworkManager will configure/up interfaces that it
# manages, so only start it if network-pre succeeded.
Requires=network-pre.target
Run sudo systemctl enable external-output-firewall.service
2 Likes
Nice!
You could also use a general purpose TemplateVM if you add
ConditionPathExists=/var/run/qubes-service/external-output-firewall
to the [Unit] section of external-output-firewall.service. Then the systemd service can be systemctl enabled in the TemplateVM, but opted into with
[user@dom0 ~]$ qvm-service --enable sys-net external-output-firewall
[user@dom0 ~]$ qvm-service --enable sys-firewall external-output-firewall
(Installing this in the general purpose TemplateVM would have the side effect of making NetworkManager require network-pre.target in all derived VMs, but I think that shouldn’t cause any problems?)
2 Likes
That’s convenient. Thanks.
Are you on the Qubes team? Would it be possible for this to be packaged up internally? The less external guides to rely on the better.
I just occasionally contribute some code to Qubes OS, but yeah this would be a great addition to the qubes-core-agent-networking package in qubes-core-agent-linux. Preventing sys-net/sys-firewall output is by far the most annoying part of preventing non-Tor (or non-VPN) traffic at the moment. Please open a pull request!
2 Likes