What risks do we add to a qube by enabling sys-firewall networking instead of “none”?

What risks do we add to a qube by enabling sys-firewall networking instead of “none”? Is it just information leakage risks or are we adding attack vectors?

I’m asking so I know what to advise for people in the guide https://forum.qubes-os.org/t/guide-for-creating-a-logging-qube-i-e-sys-log-wip/6587 , where a sys-log qube will collect logs.

If networking adds attack vectors, then could turn off networking on sys-log and have a seperate sys-log-forwarding qube that was the same as sys-log but it forwarded packets to a syslog server across the network (I.E. to a physical system outside of dom0).

If we are only adding information leak risks, then there would be no point of having seperate qubes as the same information would leak from sys-log-forwarding. However if we are adding attack vectors by doing it, that could mean that in some cases sys-log-forwarding would end up with compromised logs, but sys-log would not. If this is the case then there would be value in recommending people create 2 seperate sys-log type qubes.


  • we could scope the firewall to just one remote syslog server)
  • also of possible value is knowing that if you are willing to send the logs unencrypted over the network, that syslog can be sent via UDP

I’m somewhat of a newb, but I think keeping networking set to “none” helps prevent a side channel attack, especially when using Tor. In any case, like I said, I am kind of a newb, but I really love this Qubes system on my computer! The more I learn to use it, the more I see its absolute power!
Edit: I know I said I am somewhat of a newb, but I’m very experienced. Like I said, somewhat of a newb! :slight_smile:

1 Like
1 Like