Security implications of setting non-networking service qubes to to Provides network

User Support
,
1

I was curious of the security implications of setting (in this case sys-audio) as a networking qube (‘Provides network’ so it would show up in the service qube, purely for aesthetic and organizational reasons.

As I am not familiar with the internal networking security of Qubes, and granted I am not setting any other qubes to use sys-audio as it’s networking qube and the networking of sys-audio to ‘none’.

Would there be any security concerns? Would it make the qube more “available” to other compromised qubes in a theoretical scenario?

2

This differentiation can be triggered directly: Edit: It doesn’t survive a system restart.

$ qvm-prefs -D sys-audio provides_network  # this will unset the servicevm feature
$ qvm-features sys-audio servicevm 1       # set it again
3

Feature servicevm = 1 without provides_network do not survive restart of sys-audio

1 Like
4

Restarting just the VM preserves the feature here, but restarting the whole system (or qubesd) indeed unsets servicevm. I should have read the linked commit more carefully, it’s right there in the domain-load handler :frowning:

5

This allows you to use sys-audio as the netvm of other qubes. And sys-audio certainly has access to your USB controllers, so if you plug an USB network device, this may expose a qube whose netvm is sys-audio to this device.

So, as long as you do not use sys-audio as a netvm, it’s fine to me.

By the way, sys-usb provides network in the default installation.

1 Like
6

Sad, I hope that commit gets fulfilled one day. I imagine it would be possible to set a simple script on boot to set sys-audio to servicevm 1 as a work around.