Sys-net won't connect without GUIVM?

User Support General
1

Hi,

I have been trying to use sys-net in a headless mode and I am seeing something strange:

user@sys-net:~ > nmcli c up id myconnection
Error: Connection activation failed: Not authorized to control networking.

The same command works as expected and connects when guivm is set to dom0.

What is the reason for this?
Why should networking need GUI?

2

NetworkManager’s default policy (via polkit) is that only user on active local session (or root) can manage networking. Without GUIVM, there is no “active local session”… But if you have qubes-core-agent-passwordless-root, that check should be bypassed.

2 Likes
3

@marmarek

Thanks for the feedback.

What is the proper way to have a minimal headless sys-net without passwordless root?

I would like to make it as small as possible, ideally having only what is strictly necessary for networking, without the extra graphics stuff that qubes-core-agent-network-manager brings in.

I think it is more appropriate to have the GUI control in the GUIVM (which is its job), thus having task-based separation. I can add e.g. a panel launcher that communicates with sys-net through qvm-run and an indicator showing connected/disconnected.

4

You are setting yourself for a failure… without this package, NM config won’t persist, DNS won’t update and few other things.

I don’t think Network Manager supports that out of the box… You either need to be root, or a user on a proper local session. I guess you can try to adjust polkit config to allow specific user, but you’d need to figure out how and what is needed on your own.

If you want to go this way, you can use qvm-run -u root (and give your GUIVM permission to call qubes.VMRootExec service on your sys-net). But be careful what you do with qvm-run output - if your sys-net is malicious, it could try to trick your launcher to do something you didn’t intended.

3 Likes
5

That sounds like a unikernel

1 Like
6

@marmarek

You are setting yourself for a failure… without this package, NM config won’t persist, DNS won’t update and few other things.

I understand that and I want to keep qubes-core-agent-network-manager. I just need to remove the graphics stuff from its dependencies:

$ apt-cache depends --installed qubes-core-agent-network-manager
  Depends: qubes-core-agent-networking
  Depends: libglib2.0-bin
  Depends: network-manager
  Depends: network-manager-gnome
 >Depends: polkitd
  Breaks: qubes-core-agent
  Replaces: qubes-core-agent

What I tried in the test template:

apt-get download qubes-core-agent-network-manager
apt-get install network-manager polkitd
# After this operation, 24.5 MB of additional disk space will be used.
# ... compared to the 338 MB in regular installation which includes graphics
dpkg -i --ignore-depends=libglib2.0-bin,network-manager-gnome qubes-core-agent-network-manager_4.3.40-1+deb13u1_amd64.deb

Result:

I can connect to the network in such sys-net using nmcli:

user@dom0:~ > qvm-run -u root -- sys-net 'nmcli c up id myconnection'
Running 'nmcli c up id myconnection on sys-net
user@dom0:~ > qvm-run --pass-io -- sys-net 'nmcli networking connectivity'
full
user@dom0:~ > qvm-run --pass-io -- sys-net 'free -m'
               total        used        free      shared  buff/cache   available
Mem:             324         186          88           2         113         138
Swap:           1023           0        1023

So, it seems the 2 dependencies I excluded are not necessary for proper networking, only for GUI.

Now, the question is how to maintain such a system. My concern is that qubes-core-agent-network-manager installed this (using dpkg) may not update correctly. Can we probably have a qubes-core-agent-network-manager-mini with the true dependencies?

@unman you are the package maintainer. What do you think about this?

7

Maybe use Debian Packages to avoid those two deps? Theoretically they might be moved to Recommends, but in practice most users do actually need them to interact with network manager, so it isn’t really optional normally.

8

@marmarek

Maybe use Debian Packages to avoid those two deps?

I was already told of this trick but that actually means first installing all dependencies, then removing some, no? For a minimal system it would be better not to install unnecessary stuff in the first place.

Theoretically they might be moved to Recommends, but in practice most users do actually need them to interact with network manager, so it isn’t really optional normally.

Quite right. Hence my suggestion to split and have both options:

qubes-core-agent-network-manager-mini
  Depends: qubes-core-agent-networking
  Depends: network-manager
  Depends: polkitd

qubes-core-agent-network-manager:
  Depends: qubes-core-agent-network-manager-mini
  Depends: libglib2.0-bin
  Depends: network-manager-gnome

Then one can install whatever suits.

XY: I am exploring the possibility to reduce the attack surface and resource requirements of most “exposed” VMs (like sys-net/usb/firewall). I think separation between GUI and underlying service-VM functionality is a meaningful step in that direction. Ideally, Qubes may ship a minimalist install option/version with headless service VMs. Along these lines, what @otter2 mentions may be an additional consideration too.

What do you say?

1 Like