Disposable /rw/config/ not saved on reboot - SELinux restorecon Solution

Hi,

THANKS FOR QUBES !!

but, i came across this situation while installing QuBes with a disposable sys-net

i edited the config files using NetworkManager on ‘sys-net’ (removed the hardware details) and copied those files to the Disposable template (dvm-sys-net)

As described in the first portion of this forum posting:

the issue

while i am able to copy the config files to dvm-sys-net

connect to dvm-sys-net from dom0 with:

qvm-run -a dvm-sys-net xterm

and, create the folders required with:

[user@dvm-sys-net: ~] sudo mkdir -p /rw/config/NM-system-connections/

copy the config files in there, and shutdown using the Qubes Manager
and restart sys-net

Unfortunately, the WIFI is not connecting automatically as expected.

it would be really great if somebody could point out the error of my ways, and explain the manner to resolve these issues.

Thanks in advance,

When you start the qube based on this dvm-sys-net disposable template, check the logs and see what’s wrong:

journalctl -b -u NetworkManager

Also check in /rw/config/NM-system-connections if your files are there.

Thanks for your suggestions @DVM

in sys-net

journalctl -b -u NetworkManager 
[ ... ] 
Dec 29 07:27:02 sys-net NetworkManager[621]: <info>  [1735475222.9811] settings: Loaded settings plugin: keyfile (internal)
Dec 29 07:27:02 sys-net NetworkManager[621]: <warn>  [1735475222.9827] keyfile: load: "/etc/NetworkManager/system-connections/wifi-New.nmconnection": failed to load connection: cannot access file: Permission denied
Dec 29 07:27:02 sys-net NetworkManager[621]: <warn>  [1735475222.9828] keyfile: load: "/etc/NetworkManager/system-connections/wifi-Old.nmconnection": failed to load connection: cannot access file: Permission denied
Dec 29 07:27:02 sys-net NetworkManager[621]: <info>  [1735475222.9877] dhcp: init: Using DHCP client 'internal'

[user@sys-net ~]$ ls -la /etc/NetworkManager/system-connections/
total 16
drwxr-xr-x. 2 root root 4096 Dec 28 13:38 .
drwxr-xr-x. 3 root root 4096 Sep  3 14:27 ..
-rw-------. 1 root root  309 Nov 25 07:12 wifi-New.nmconnection
-rw-------. 1 root root  351 Sep 30 12:45 wifi-Old.nmconnection

And, for some reason, the /run/config in dvm-sys-dev seems to have resolved itself;
Truth be told, there were changes to the permissions and ownership of the files as [ root:root , 0600 ]

thus, in dvm-sys-net :


[user@dvm-sys-net ~]$ sudo ls -lah /etc/NetworkManager/
total 32K
drwxr-xr-x.   7 root root 4.0K Dec 23 09:25 .
drwxr-xr-x. 119 root root 4.0K Dec 29 10:20 ..
-rw-r--r--.   1 root root 2.3K Dec 23 09:25 NetworkManager.conf
drwxr-xr-x.   2 root root 4.0K Jun 23  2024 conf.d
drwxr-xr-x.   5 root root 4.0K Dec 23 09:25 dispatcher.d
drwxr-xr-x.   2 root root 4.0K Jun 23  2024 dnsmasq-shared.d
drwxr-xr-x.   2 root root 4.0K Jun 23  2024 dnsmasq.d
drwxr-xr-x.   2 root root 4.0K Jun 23  2024 system-connections
[user@dvm-sys-net ~]$ sudo ls -lah /rw/config/NM-system-connections/
total 16K
drw-------. 2 root root 4.0K Dec 28 13:38 .
drwxr-xr-x. 3 root root 4.0K Sep  3 14:27 ..
-rw-------. 1 root root  289 Dec 29 09:26 wifi-New.nmconnection
-rw-------. 1 root root  289 Dec 29 09:26 wifi-Old.nmconnection


Thanks to your suggestions, dvm-sys-net appears to be solved after files & directories permissions were fixed as per warn found in journalctrl

outstanding issue
sys-net is not using the config ((*.nmconnection)) files due permissions ?

Thanks,

Could it be a SELinux issue?
Do you see any denied logs related to the NetworkManager connection?

journalctl -b | grep denied

yes, there are entries found …


[user@sys-net ~]$ sudo journalctl -b | grep -i denied
Dec 29 09:38:14 sys-net audit[622]: AVC avc:  denied  { getattr } for  pid=622 comm="NetworkManager" path="/rw/config/NM-system-connections/wifi-New.nmconnection" dev="xvdb" ino=115 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:qubes_unpacked_file_t:s0 tclass=file permissive=0
Dec 29 09:38:14 sys-net audit[622]: AVC avc:  denied  { getattr } for  pid=622 comm="NetworkManager" path="/rw/config/NM-system-connections/wifi-Old.nmconnection" dev="xvdb" ino=108 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:qubes_unpacked_file_t:s0 tclass=file permissive=0
Dec 29 09:38:14 sys-net NetworkManager[622]: <warn>  [1735483094.0054] keyfile: load: "/etc/NetworkManager/system-connections/wifi-New.nmconnection": failed to load connection: cannot access file: Permission denied
Dec 29 09:38:14 sys-net NetworkManager[622]: <warn>  [1735483094.0054] keyfile: load: "/etc/NetworkManager/system-connections/wifi-Old.nmconnection": failed to load connection: cannot access file: Permission denied


What happens if you run this on both files in the disposable template:

restorecon -v /rw/config/NM-system-connections/wifi-New.nmconnection
restorecon -v /rw/config/NM-system-connections/wifi-Old.nmconnection
1 Like

below are the result of commands;

[user@dvm-sys-net ~]$ sudo restorecon -v /rw/config/NM-system-connections/wifi-New.nmconnection
Relabeled /rw/config/NM-system-connections/wifi-New.nmconnection from unconfined_u:object_r:qubes_unpacked_file_t:s0 to unconfined_u:object_r:NetworkManager_etc_rw_t:s0

[user@dvm-sys-net ~]$ sudo restorecon -v /rw/config/NM-system-connections/wifi-Old.nmconnection
Relabeled /rw/config/NM-system-connections/wifi-Old.nmconnection from unconfined_u:object_r:qubes_unpacked_file_t:s0 to unconfined_u:object_r:NetworkManager_etc_rw_t:s0

Thanks @DVM

I have restarted sys-net (a few times) and it is now connecting by itself - as expected !!

Would you mind giving some idea for this issue ?

1 Like

Do you want me to explain what fixed the issue or something else?

I figure that there were SELinux interfering in the process.

However, it is not clear why QuBes /rw/config implementation would not have taken SELinux into consideration.

The sys-usb & sys-net are using Fedora templates - since Fedora appears to be better supported by QuBes.

So it is a curious thing to find this issue.

Is this a Bug that should be reported ?

Thanks for your assistance

You had this issue because you moved both files from another qube, which changed their labels to something else related to the qube’s unpacker binary used to exchange files between qubes.
Since SELinux is strict about what services can access what, NetworkManager couldn’t access the two configuration files because they weren’t labeled with its own labels. restorecon restored the labels to the correct NetworkManager_etc_rw_t label, which allowed NetworkManager to access them.

3 Likes

Thanks @DVM for parting this information!

It is super important - and helpful - for the newbies, such as myself, to understand these issues.

It is also super important to mark @DVM 's solution as “SOLUTION” so people find it quickly,

thanks @barto

flagged the solution - still getting used to the forum’s web-app