Description of problem: This alert starts as soon as I login and continues to happen every 5-10 seconds SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that NetworkManager should be allowed watch access on the VPN directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'NetworkManager' --raw | audit2allow -M my-NetworkManager # semodule -X 300 -i my-NetworkManager.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:NetworkManager_etc_t:s0 Target Objects /etc/NetworkManager/VPN [ dir ] Source NetworkManager Source Path NetworkManager Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.7-23.fc34.noarch Local Policy RPM selinux-policy-targeted-3.14.7-23.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.11.2-300.fc34.x86_64 #1 SMP Fri Feb 26 17:05:35 UTC 2021 x86_64 x86_64 Alert Count 277 First Seen 2021-03-03 10:26:25 MST Last Seen 2021-03-03 11:00:15 MST Local ID 1517d6f9-f56d-452f-ab7e-63830b2fb256 Raw Audit Messages type=AVC msg=audit(1614794415.431:1275): avc: denied { watch } for pid=1292 comm="gmain" path="/etc/NetworkManager/VPN" dev="dm-1" ino=2228376 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=dir permissive=0 Hash: NetworkManager,NetworkManager_t,NetworkManager_etc_t,dir,watch Version-Release number of selected component: selinux-policy-targeted-3.14.7-23.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.11.2-300.fc34.x86_64 type: libreport
Similar problem has been detected: Seen after dnf version upgrade. hashmarkername: setroubleshoot kernel: 5.11.6-300.fc34.x86_64 package: selinux-policy-targeted-3.14.7-25.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Hi folks, Do you happen to know where this directory comes from or which service creates it? It seems not to be a part of any package and I cannot reproduce it. /etc/NetworkManager/VPN
Mine is old and empty: [root@xps ~]# ll -dZ /etc/NetworkManager/VPN drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 Apr 20 2018 /etc/NetworkManager/VPN I don't think I created it manually. I also don't think I ever configured any global VPN. But it seems like the directory was created but not owned until https://src.fedoraproject.org/rpms/NetworkManager-openvpn/c/af16c1552615a73c6cd8d732c88f52260b56e837 . I guess the options are: - deal with it in SE - deal with it in NM for some time (by creating&owning or rmdir in a %script) ... but that would not be reliable and still require dealing with it in SE But it would still be a bug if NetworkManager-openvpn were built with libnm_glib again - perhaps better to just clean up and remove that option.
*** Bug 1939235 has been marked as a duplicate of this bug. ***
Mads, Thank you for your inputs, switching the component to NM for the maintainers to assess.
Similar problem has been detected: I upgraded from F33 to F34 beta, and then rebooted hashmarkername: setroubleshoot kernel: 5.11.7-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: SELinux notification after logging into GNOME. - It keeps popping up constantly even if I click "Ignore". hashmarkername: setroubleshoot kernel: 5.11.7-300.fc34.x86_64 package: selinux-policy-targeted-3.14.7-25.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directório /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgraded to F34 beta, and this is happening constantly. hashmarkername: setroubleshoot kernel: 5.11.11-300.fc34.x86_64 package: selinux-policy-targeted-34-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Should this be a release blocker? Or is it OK that a clean upgrade path ends up with repeated SE policy violation reports?
Based on your diagnosis above, probably not a blocker, since the criteria only cover upgrades from the last two releases. We don't really want to tie ourselves to the standard that upgrades will work perfectly for a very long upgrade chain, things like this *are* likely to pop up over time. It would be good to fix it, though.
Hi Lubomir, Can you please look on the comment#5 ? Thanks, Lukas.
The directory was empty, so I've just removed it. I do have configured VPNs.
Similar problem has been detected: Upgrade to F34. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: I just upgraded to Fedora 34. I have one VPN connection configured in NetworkManager. hashmarkername: setroubleshoot kernel: 5.11.12-300.fc34.x86_64 package: selinux-policy-targeted-34-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the hakemisto /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: upgraded from f33 to f34 hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the dossier /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Happened immediately on boot after upgrade from Fedora 33 to Fedora 34 hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: After Fedora 33 to Fedora 34 upgrade this happens, right after the first start. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: First boot after upgrade to FC34. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgraded from Fedora 32 to 34. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: right after upgrade to fc34 hashmarkername: setroubleshoot kernel: 5.11.16-200.fc33.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Fresh upgrade from Fedora 33 to 34 hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgraded to Fedora 34 from 33. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the könyvtár /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgraded from Fedora 33 to Fedora 34 through gnome-software. Continuesly popping up even after a restart. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
The same problem, upgraded from f33 -> f34, I did relabel, it triggers periodically cca. once per second, very annoying.
Similar problem has been detected: Just on KDE plasma start-up I've got this denial. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Just after startup. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: I just upgraded my laptop from Fedora 33 to 34, and upon reboot this error started happening (a new notification pops up about every 3s, very annnoying). This hadn't been observed on Fedora 33. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: updated to Fedora 34 hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgraded to Fedora34 and this error is constantly popping up. hashmarkername: setroubleshoot kernel: 5.11.16-200.fc33.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: I upgraded Fedora Workstation Edition from 33 to 34, and these errors started showing up. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: I can only say that this error is related to Networkmanager and that I have two VPN configured, but not automatically enabled. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the cartella /etc/NetworkManager/VPN. type: libreport
I had the same issue (with gmain) just after upgrading to F34: type=AVC msg=audit(1619865900.723:985): avc: denied { watch } for pid=1204 comm="gmain" path="/etc/NetworkManager/VPN" dev="dm-0" ino=2097292 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=dir permissive=0 As root, `restorecon -Rv /etc/NetworkManager` didn't solve the issue, but `rmdir /etc/NetworkManager/VPN` did solve it for me.
Occurs on F33 to F34 system-upgrade. Shows popup every 4 seconds. workaround: # systemctl stop NetworkManager ps. The SE detail info doesn't give the name of the binary repeatedly trying to perform the access, although it mentions gmain. $ which gmain does not find anything. $ locate --all --ignore-case gmain also only matches some header files: /usr/include/glib-2.0/glib/gmain.h Can the "accounting"/ SE detail tell us directly the name of the executable/process/script which is triggering the denial ?
$ rpm -qa |grep Network |sort NetworkManager -1.30.4-1.fc34.x86_64 NetworkManager-adsl -1.30.4-1.fc34.x86_64 NetworkManager-bluetooth -1.30.4-1.fc34.x86_64 NetworkManager-iodine -1.2.0-12.fc34.x86_64 NetworkManager-iodine-gnome -1.2.0-12.fc34.x86_64 NetworkManager-l2tp -1.8.6-5.fc34.x86_64 NetworkManager-l2tp-gnome -1.8.6-5.fc34.x86_64 NetworkManager-libnm -1.30.4-1.fc34.x86_64 NetworkManager-libreswan -1.2.14-1.fc34.1.x86_64 NetworkManager-libreswan-gnome-1.2.14-1.fc34.1.x86_64 NetworkManager-openconnect -1.2.6-6.fc34.x86_64 NetworkManager-openvpn -1.8.14-1.fc34.x86_64 NetworkManager-openvpn-gnome -1.8.14-1.fc34.x86_64 NetworkManager-pptp -1.2.8-2.fc34.2.x86_64 NetworkManager-pptp-gnome -1.2.8-2.fc34.2.x86_64 NetworkManager-sstp -1.2.6-8.fc34.x86_64 NetworkManager-sstp-gnome -1.2.6-8.fc34.x86_64 NetworkManager-team -1.30.4-1.fc34.x86_64 NetworkManager-vpnc -1.2.6-6.fc34.x86_64 NetworkManager-vpnc-gnome -1.2.6-6.fc34.x86_64 NetworkManager-wifi -1.30.4-1.fc34.x86_64 NetworkManager-wwan -1.30.4-1.fc34.x86_64 - workaround 2: # dnf remove NetworkManager-openvpn-gnome # systemctl stop NetworkManager # systemctl start NetworkManager
(In reply to David Timms from comment #34) ... > - workaround 2: > # dnf remove NetworkManager-openvpn-gnome > # systemctl stop NetworkManager > # systemctl start NetworkManager Spoke too soon, workaround 2 does not work. neither does: dnf remove NetworkManager-openvpn (In reply to Mads Kiilerich from comment #3) > [root@xps ~]# ll -dZ /etc/NetworkManager/VPN > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 Apr > 20 2018 /etc/NetworkManager/VPN $ ls -lZ /etc/NetworkManager/ ... drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 Oct 6 2018 VPN Same as comment #3, I didn't create the folder manually, and don't have any VPNs configured currently. # rmdir /etc/NetworkManager/VPN succeeds in stopping the continuous notifications without other changes.
Similar problem has been detected: This is right after an update to Fedora 34. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
In my case, the directory /etc/NetworkManage/VPN was three years old (and empty). My guess is that it was part of Fedora 34-3*2 = 28. I deleted the directory and the message went away (but I've only tested for seconds). I wonder if every system upgraded from Fedora 28 has this problem. It's annoying and alarming but I guess that it's harmless. It should go in the release notes (perhaps it is).
My system was certainly once Fedora 28.
The %{_sysconfdir}/%{name}/VPN directory was removed from the spec file in https://src.fedoraproject.org/rpms/NetworkManager/c/a486a6825, for NetworkManager 1.8, i.e. for Fedora 26.
Similar problem has been detected: Booted then logged into GNOME. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
> The %{_sysconfdir}/%{name}/VPN directory was removed from the spec file in https://src.fedoraproject.org/rpms/NetworkManager/c/a486a6825, for NetworkManager 1.8, i.e. for Fedora 26. The package should probably cleanup the directory then if it used to make it and just stopped making it.
(In reply to Ian McInerney from comment #41) > > The %{_sysconfdir}/%{name}/VPN directory was removed from the spec file in https://src.fedoraproject.org/rpms/NetworkManager/c/a486a6825, for NetworkManager 1.8, i.e. for Fedora 26. > > The package should probably cleanup the directory then if it used to make it > and just stopped making it. I am not sure it is really not used anymore. Maybe user-defined service files can be dropped there (in contrast to the package-provided ones, which are now in /usr/lib/NetworkManager/VPN). At least some process is watching or trying to access this directory, that's why we are seeing the SELinux messages. The interesting questions is, what SELinux policy changed between f33 and f34, and why, and if, can it be reverted?
Similar problem has been detected: I upgraded to Fedora 34 from 33, and booted system for the first time. I have two OpenVPN connections in the network managers. They are not configurated to be activated automatically on a boot. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the каталог /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Updated from Fedora 33 to 34 and this is one of the errors I get hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Alert appearing at login following the upgrade Fedora 33 -> 34 via https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/. In particular, issued `sudo fixfiles -B onboot`. hashmarkername: setroubleshoot kernel: 5.11.16-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgrade from F32 to F34, first boot hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Upgrade F32 to F34, 1st boot after "sudo fixfiles -B onboot" hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
I would say this is a common bug and the workaround of deleting the directory should be working in most cases. Maybe some scriptlet could check whether the directory is empty and just delete it in that case? Could that be implemented on short notice for a smoother the upgrade experience? Additionally I think this could/should be added to the common bugs section, could someone take care of that?
yeah, was thinking the same.
Similar problem has been detected: This issue occurs since the upgrade to Fedora 34 (from 33) -> every four seconds. hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 reason: SELinux is preventing NetworkManager from 'watch' accesses on the Verzeichnis /etc/NetworkManager/VPN. type: libreport
I took a shot at it: https://fedoraproject.org/wiki/Common_F34_bugs#NetworkManager I'm not the greatest writer, all improvements welcome. I'd still like to see the NM maintainers add a scriptlet which automatically removes this directory if empty.
Similar problem has been detected: This started happening after F33->F34 upgrade (dnf system-upgrade). hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.4-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
*** Bug 1956805 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Started GNOME hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.4-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Log into GNOME hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.4-1.fc34.noarch reason: SELinux is preventing gmain from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
I can confirm that after removing /etc/NetworkManager/VPN, I see no more denials. Thanks!
This is hideous. It results in a constant barrage of popups of the SELinux security alert notification. While I understand there is a simple workaround to just remove the empty dir, EVERY F34 user should not have to come looking for bug reports to stop this hideous behaviour upon an upgrade to F34. Will an updated package that takes care of this problem be issued?
It doesn't affect "every F34 user". Only people who have upgraded constantly since Fedora 25 or earlier. BTW, another easy workaround is just to tell selinux-troubleshoot to ignore the notification. There's a button for that. NM maintainers, are you in favour having a scriptlet to clean this up? Thanks for writing the common bugs entry, David, I'll just tweak it a little bit to follow 'house style' :)
I have also opened an issue in the selinux-policy repo to let the selinux people know this issue exists (https://github.com/fedora-selinux/selinux-policy/issues/717), since one other way to fix this would be to have selinux allow access to the directory.
The bug was filed against selinux-policy in the first place. The SELinux policy maintainer (zpytela) already looked at it, see initial comments. He is the one who reassigned it to NM.
But looking at https://github.com/NetworkManager/NetworkManager/blob/23a200d19e25fb760a69dd818dad1b780352b8c4/src/libnm-core-impl/nm-vpn-plugin-info.c#L315 it seems to me that a VPN plugin can still be defined in /etc/NetworkManager/VPN, so wouldn't the right thing be to fix the selinux policy to allow the directory to exist and be accessed?
Possibly, but we're still waiting for someone from NM team to assess it. Looking at the package changelog, Lubomir hasn't touched it since 2019, so possibly he's not the best person. Let me ping some others too.
it's not clear to me how to fix this. NetworkManager still honors the directory, so that VPN plugins can drop their .name files there. For that reason, the directory maybe should be owned by NetworkManager too (aside the VPN plugins that drop files there). But, for NetworkManager it's also fine (and preferable) if the directory does not exist. So can the NetworkManager package own the directory? Anyway, more interesting is what changed in Fedora 34 (SELinux) that causes this problem now. I don't think that NetworkManager changed anything there. I would prefer if SELinux fixes this and allows NetworkManager to access the directory (if it exists). Is that possible?
(In reply to Thomas Moschny from comment #42) > The interesting questions is, what SELinux policy changed between f33 and > f34, and why, and if, can it be reverted? A group of new permissions (watch) were defined in selinux-policy in F34 to discern watch from read. https://fedoraproject.org/wiki/Changes/Make_selinux_policy_uptodate_with_current_kernel
(In reply to Zdenek Pytela from comment #64) > (In reply to Thomas Moschny from comment #42) > > The interesting questions is, what SELinux policy changed between f33 and > > f34, and why, and if, can it be reverted? > A group of new permissions (watch) were defined in selinux-policy in F34 to > discern watch from read. > https://fedoraproject.org/wiki/Changes/ > Make_selinux_policy_uptodate_with_current_kernel Ah, so https://github.com/fedora-selinux/selinux-policy/pull/546 needs to be amended with watch permissions for NM for that directory?
(In reply to Thomas Haller from comment #63) > it's not clear to me how to fix this. > > > NetworkManager still honors the directory, so that VPN plugins can drop > their .name files there. > For that reason, the directory maybe should be owned by NetworkManager too > (aside the VPN plugins that drop files there). > But, for NetworkManager it's also fine (and preferable) if the directory > does not exist. So can the NetworkManager package own the directory? > > > Anyway, more interesting is what changed in Fedora 34 (SELinux) that causes > this problem now. > I don't think that NetworkManager changed anything there. New watch permissions were added to kernel and policy. > > > I would prefer if SELinux fixes this and allows NetworkManager to access the > directory (if it exists). Is that possible? Switching the component back to selinux-policy. Still I think it can be dealt with in nm too, e. g. having /etc/NetworkManager/VPN a %ghost file in the package. If I understand https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/8232c3473f93a87e2eb736bf4b63049001a20926/src/core/vpn/nm-vpn-manager.c#L207 nm needs to watch /var/lib/NetworkManager/VPN too, but these permissions are already present: # sesearch -A -s NetworkManager_t -t NetworkManager_var_lib_t -c dir -p watch allow NetworkManager_t NetworkManager_var_lib_t:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink watch watch_reads write }; # sesearch -A -s NetworkManager_t -t NetworkManager_etc_t -c dir allow NetworkManager_t NetworkManager_etc_t:dir { add_name getattr ioctl lock open read remove_name search write }; Additionally, I found /lib/firmware which also has the permission: # sesearch -A -s NetworkManager_t -t lib_t -c dir allow NetworkManager_t lib_t:dir watch; Hope that's all.
A PR merged, will be in the next build: https://github.com/fedora-selinux/selinux-policy/pull/718
> Still I think it can be dealt with in nm too, e. g. having /etc/NetworkManager/VPN a %ghost file in the package. Why/how does %ghost solve this issue?
Similar problem has been detected: Log in after upgrade from Fedora 33 to 34. hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.4-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: Pops a notification over and over. hashmarkername: setroubleshoot kernel: 5.11.15-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
Similar problem has been detected: This occured when I first logged in after dnf system upgrade hashmarkername: setroubleshoot kernel: 5.11.17-300.fc34.x86_64 package: selinux-policy-targeted-34.5-1.fc34.noarch reason: SELinux is preventing NetworkManager from 'watch' accesses on the directory /etc/NetworkManager/VPN. type: libreport
FEDORA-2021-de55424c01 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-de55424c01
(In reply to Thomas Haller from comment #68) > > Still I think it can be dealt with in nm too, e. g. having /etc/NetworkManager/VPN a %ghost file in the package. > > Why/how does %ghost solve this issue? It does not solve it, but it could help with searching for the package which works with the directory.
FEDORA-2021-de55424c01 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-de55424c01` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-de55424c01 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks for the quick update! I think we can move the entry as F34 common bug to the resolved section once this update hits stable.
FEDORA-2021-de55424c01 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
> I think we can move the entry as F34 common bug to the resolved section once this update hits stable. Done. Thanks again!
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days