Description of problem: On a fresh install of Fedora 36 testing branch.Scripts lying in /etc/NetworkManager/dispatcher.d cannot be executed by nm-dispatcher. Version-Release number of selected component (if applicable): Name : selinux-policy Version : 36.3 Release : 1.fc36 Architecture : noarch Size : 25 k Source : selinux-policy-36.3-1.fc36.src.rpm How reproducible: Steps to Reproduce: 1. Set up a VPN connection in Network Manager 2. place a script in /etc/NetworkManager/dispatcher.d 3. bring up VPN connection Actual results: Script is not executed. Journalctl: nm-dispatcher[4377]: req:2 'vpn-up' [ppp0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Expected results: The script is executed Additional info: This works fine in Fedora 35. I know that there is: https://bugzilla.redhat.com/show_bug.cgi?id=2053388 But this only concerns RHEL. And I think that this is a critical stopper for beta of Fedora 36 also ?
(In reply to sascha.appel from comment #0) > Description of problem: > > On a fresh install of Fedora 36 testing branch.Scripts lying in > /etc/NetworkManager/dispatcher.d cannot be executed by nm-dispatcher. > > Version-Release number of selected component (if applicable): > > Name : selinux-policy > Version : 36.3 > Release : 1.fc36 > Architecture : noarch > Size : 25 k > Source : selinux-policy-36.3-1.fc36.src.rpm > > > How reproducible: > > > Steps to Reproduce: > 1. Set up a VPN connection in Network Manager > 2. place a script in /etc/NetworkManager/dispatcher.d > 3. bring up VPN connection > > Actual results: > Script is not executed. Journalctl: > > nm-dispatcher[4377]: req:2 'vpn-up' [ppp0]: find-scripts: Failed to open > dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening > directory “/etc/NetworkManager/dispatcher.d”: Permission denied > > Expected results: > The script is executed > > Additional info: > This works fine in Fedora 35. I know that there is: > > https://bugzilla.redhat.com/show_bug.cgi?id=2053388 > > But this only concerns RHEL. And I think that this is a critical stopper for > beta of Fedora 36 also ? Changes in the policy usually go to Fedora first. Please try with the latest selinux-policy-36.5-1.fc36 build, report AVC denials if there are any, and include reproducing steps.
I tried it with selinux-policy-36.5-1.fc36, no change. However I could not see any AVC denials. Journalctl logs still the same error: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Maybe this is not selinux related?
(In reply to sascha.appel from comment #2) > I tried it with selinux-policy-36.5-1.fc36, no change. However I could not > see any AVC denials. Journalctl logs still the same error: > > find-scripts: Failed to open dispatcher directory > '/etc/NetworkManager/dispatcher.d': Error opening directory > “/etc/NetworkManager/dispatcher.d”: Permission denied > > Maybe this is not selinux related? It can be DAC permissions which should be easy to verify, but I'd rather suspect dontaudit rules which can be temporarily disabled: If you can, please do the following: semodule -DB <reproduce> semodule -B ausearch -i -m avc,user_avc -ts recent
Result of the above steps, a lot of log output that looks like this: type=AVC msg=audit(03/24/2022 09:52:44.291:536) : avc: denied { noatsecure } for pid=3008 comm=nm-dispatcher scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tclass=process permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.292:537) : avc: denied { read write } for pid=3008 comm=20-chrony-onoff path=socket:[29332] dev="sockfs" ino=29332 scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.292:538) : avc: denied { read write } for pid=3008 comm=20-chrony-onoff path=socket:[29332] dev="sockfs" ino=29332 scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.292:539) : avc: denied { rlimitinh } for pid=3008 comm=20-chrony-onoff scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tclass=process permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.292:540) : avc: denied { siginh } for pid=3008 comm=20-chrony-onoff scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tclass=process permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.298:541) : avc: denied { noatsecure } for pid=3009 comm=20-chrony-onoff scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:chronyc_t:s0 tclass=process permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.299:542) : avc: denied { rlimitinh } for pid=3009 comm=chronyc scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:chronyc_t:s0 tclass=process permissive=0 ---- type=AVC msg=audit(03/24/2022 09:52:44.299:543) : avc: denied { siginh } for pid=3009 comm=chronyc scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:chronyc_t:s0 tclass=process permissive=0
hm. I see the same problem, I also suspect SELinux. I tried downgrading to an selinux-package selinux-policy-35.7-1.fc36, `touch /.autorelabel && reboot` and could not see the issue. Also, `setenforce 0` makes the errors go away. However, with the steps from comment 3 I could not get useful AVC warnings. I say this, because it seems to me that the messages from comment 4 are not really the ones that cause the first problem. Because, with `setenforce 0`, the dispatcher service starts executing the scripts, and this results in different warnings (more like the ones from comment 4). But the first problem is that dispatcher script cannot access the /etc/NetworkManager/dispatcher.d directory.
I realize that this is related to my RHEL RFE to rework the labeling for the NM-dispatcher service. I am sorry for the fallout, but thank you Zdenek for your work on this!!
(In reply to Thomas Haller from comment #5) > hm. I see the same problem, I also suspect SELinux. > > I tried downgrading to an selinux-package selinux-policy-35.7-1.fc36, `touch > /.autorelabel && reboot` and could not see the issue. Note the first package version with nm-disp support was 36.1-1. Since then, every update contains some related changes. > Also, `setenforce 0` makes the errors go away. > > However, with the steps from comment 3 I could not get useful AVC warnings. If setenforce 0 helps, dontaudit rules should be the first thing to check. In the previous comment, there was only one which I am not sure how it could be related, but a simple policy module is worth a go: # cat local_nmdisp_init.cil (allow NetworkManager_dispatcher_chronyc_t init_t (unix_stream_socket (read write))) # semodule -i local_nmdisp_init.cil > I say this, because it seems to me that the messages from comment 4 are not > really the ones that cause the first problem. > Because, with `setenforce 0`, the dispatcher service starts executing the > scripts, and this results in different warnings (more like the ones from > comment 4). > But the first problem is that dispatcher script cannot access the > /etc/NetworkManager/dispatcher.d directory. Do yo know which script it is? This one: /usr/lib/NetworkManager/dispatcher.d/20-chrony-onoffline seems to just execute chronyc and not doing anything else, except for internal bash commands. (In reply to Thomas Haller from comment #6) > I realize that this is related to my RHEL RFE to rework the labeling for the > NM-dispatcher service. > I am sorry for the fallout, but thank you Zdenek for your work on this!! No need for being sorry, it just turned out to be reasonably more convoluted. The problem is I cannot reproduce errors of other users.
This one is really easy to reproduce if you boot a rawhide instance (any way you choose). One way to do it is with Vagrant and this Vagrantfile: ``` Vagrant.configure(2) do |config| config.ssh.insert_key = 'true' config.vm.provider :libvirt do |domain| domain.memory = 4096 domain.cpus = 4 domain.nested = true end host = 'vanilla-rawhide' # Grab latest successful compose ID require 'open-uri' uri = URI.parse("https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID") id = uri.read # Grab the date type respin string from that datetyperespin = /(\d{8}\.n\.\d)/.match(id)[0] # Derive the box url from those two box_url = "https://kojipkgs.fedoraproject.org/compose/rawhide/#{id}/compose/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-#{datetyperespin}.x86_64.vagrant-libvirt.box" box = "rawhide-cloud-base-#{datetyperespin}" config.vm.define host do | tmp | tmp.vm.hostname = host tmp.vm.box = box tmp.vm.box_url = box_url end end ```
Proposed as a Freeze Exception for 36-final by Fedora user dustymabe using the blocker tracking app because: Would be nice to not have NM dispatchers working and not see Permission Denied errors show up in the bootup logs.
*** Bug 2070042 has been marked as a duplicate of this bug. ***
Discussed using the asynchronous bug tracking platform: [0] The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update. [0] https://qa.fedoraproject.org/blockerbugs/
(In reply to Geoffrey Marr from comment #11) > [0] https://qa.fedoraproject.org/blockerbugs/ The link should've been: https://pagure.io/fedora-qa/blocker-review/issue/701
Hi, Can you check your scenarios with the latest build? https://bodhi.fedoraproject.org/updates/FEDORA-2022-76963fee71
I still see the denied messages in the journal: ``` [core@localhost ~]$ rpm -q selinux-policy selinux-policy-36.7-1.fc36.noarch [core@localhost ~]$ journalctl | grep denied Apr 21 17:46:07 localhost.localdomain nm-dispatcher[1369]: req:1 'hostname': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:07 localhost.localdomain nm-dispatcher[1369]: req:2 'connectivity-change': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:08 localhost.localdomain nm-dispatcher[1369]: req:3 'hostname': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:4 'dhcp4-change' [enp2s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:5 'dhcp4-change' [enp1s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:6 'pre-up' [enp2s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d/pre-up.d': Error opening directory “/etc/NetworkManager/dispatcher.d/pre-up.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:7 'pre-up' [enp1s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d/pre-up.d': Error opening directory “/etc/NetworkManager/dispatcher.d/pre-up.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:8 'up' [enp2s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:9 'connectivity-change': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:10 'up' [enp1s0]: find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied Apr 21 17:46:14 localhost.localdomain nm-dispatcher[1369]: req:11 'hostname': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied ```
Can you list the directory, check the labels, display audit records? ls -lZa /etc/NetworkManager/dispatcher.d restorecon -Rvn /etc/NetworkManager/dispatcher.d ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
I don't have `ausearch` on this system (it's Fedora CoreOS) but here are the first two items: ``` [core@cosa-devsh ~]$ ls -lZa /etc/NetworkManager/dispatcher.d total 4 drwxr-xr-x. 5 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 111 Apr 21 17:40 . drwxr-xr-x. 7 root root system_u:object_r:NetworkManager_etc_t:s0 134 Apr 21 17:40 .. -rwxr--r--. 1 root root system_u:object_r:NetworkManager_dispatcher_console_script_t:s0 491 Apr 21 17:40 90-console-login-helper-messages-gensnippet_if drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 6 Apr 21 17:40 no-wait.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 6 Apr 21 17:40 pre-down.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 6 Apr 21 17:40 pre-up.d [core@cosa-devsh ~]$ [core@cosa-devsh ~]$ [core@cosa-devsh ~]$ restorecon -Rvn /etc/NetworkManager/dispatcher.d [core@cosa-devsh ~]$ ``` There are no SELinux denials by default. If I disable dontaudit rules `semodule -DB` and I `nmcli c down` and `nmcli c up` the connection then I see a bunch of denials in the journal (attached).
Created attachment 1874218 [details] dontaudit denials
Thank you, this probably is the matching record: Apr 21 18:26:15 cosa-devsh kernel: audit: type=1400 audit(1650565575.562:324): avc: denied { search } for pid=1677 comm="nm-dispatcher" name="NetworkManager" dev="vda4" ino=852975 scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=dir permissive=0 Apr 21 18:26:15 cosa-devsh kernel: audit: type=1300 audit(1650565575.562:324): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5654843591f0 a2=90800 a3=0 items=0 ppid=1 pid=1677 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-dispatcher" exe="/usr/libexec/nm-dispatcher" subj=system_u:system_r:NetworkManager_dispatcher_t:s0 key=(null) So it fails to open the plugins parent directory. I just wonder why the denial did not appear on my systems.
FEDORA-2022-47789bbc9d has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-47789bbc9d
FEDORA-2022-47789bbc9d has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-47789bbc9d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-47789bbc9d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Still have problem with latest build. type=AVC msg=audit(1651197550.94:395): avc: denied { execute } for pid=4185 comm="start-statd" name="rpc.statd" dev="dm-0" ino=419160 scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:object_r:rpcd_exec_t:s0 tclass=file permissive=0
(In reply to Mike Basinger from comment #21) > Still have problem with latest build. > > type=AVC msg=audit(1651197550.94:395): avc: denied { execute } for pid=4185 > comm="start-statd" name="rpc.statd" dev="dm-0" ino=419160 > scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 > tcontext=system_u:object_r:rpcd_exec_t:s0 tclass=file permissive=0 This particular problem has not been reported yet, do you know which script triggers this denial?
Hey Mike Basinger, I think you need to open a new BZ. The problem from this BZ got solved but now there are new (additional) issues that are uncovered because we can get to the next level. For example, my team opened https://bugzilla.redhat.com/show_bug.cgi?id=2080043 as a follow on to this bug. I believe each dispatcher will need to be evaluated and policy written for since the dispatchers are now confined. You'll most likely need to find which dispatcher script is triggering that denial and file a bug for that.
(In reply to Zdenek Pytela from comment #22) > (In reply to Mike Basinger from comment #21) > > Still have problem with latest build. > > > > type=AVC msg=audit(1651197550.94:395): avc: denied { execute } for pid=4185 > > comm="start-statd" name="rpc.statd" dev="dm-0" ino=419160 > > scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 > > tcontext=system_u:object_r:rpcd_exec_t:s0 tclass=file permissive=0 > > This particular problem has not been reported yet, do you know which script > triggers this denial? I have written a dispatcher script that mounts some NFS shares when on I'm on my home network. It works fine when selinux is in permissive mode. #!/usr/bin/sh # Find the connection UUID with "nmcli con show" in terminal. # All NetworkManager connection types are supported: wireless, VPN, wired... HOME_UUID="bcea6477-20fa-4d2f-987c-2e0c8188e772" if [[ "$CONNECTION_UUID" == "$HOME_UUID" ]]; then # Script parameter $1: NetworkManager connection name, not used # Script parameter $2: dispatched event case "$2" in "up") mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/books /mnt/vault/books mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/music /mnt/vault/music mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/photo /mnt/vault/photos mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/games /mnt/vault/games mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/video /mnt/vault/video mount -t nfs -o rsize=8192,wsize=8192,timeo=14 192.168.1.5:/volume1/backups /mnt/vault/backups ;; "pre-down");& "vpn-pre-down") umount -l -a -t -f nfs4,nfs >/dev/null ;; esac fi
Interesting. So it's a custom script that you wrote and not something provided by the distribution. Zdenek, I wonder if we need an seboolean knob for reverting to the old behavior for cases like this? i.e. things provided by the distro (RPMs) should have a proper policy created, but we can hardly expect users to come up with their own policy for every script they write.
setroubleshootd said the following would resolve issue, but it does not ausearch -c 'start-statd' --raw | audit2allow -M my-startstatd semodule -X 300 -i my-startstatd.pp [root@laptop ~]# more my-startstatd.te module my-startstatd 1.0; require { type rpcd_exec_t; type NetworkManager_dispatcher_t; type rpcd_lock_t; type var_run_t; class dir { add_name write }; class file { create getattr open write }; } #============= NetworkManager_dispatcher_t ============== #!!!! This avc is allowed in the current policy allow NetworkManager_dispatcher_t rpcd_exec_t:file getattr; #!!!! This avc is allowed in the current policy allow NetworkManager_dispatcher_t rpcd_lock_t:file write; #!!!! This avc is allowed in the current policy allow NetworkManager_dispatcher_t var_run_t:dir { add_name write }; #!!!! This avc is allowed in the current policy allow NetworkManager_dispatcher_t var_run_t:file { create open write };
FEDORA-2022-47789bbc9d has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.