Description of problem: I am running Fedora Server with SELinux enabled. I symlinked /run/systemd/resolve/resolv.conf to /etc/resolv.conf and disabled the DNS stub resolver of systemd-resolved via /etc/systemd/resolved.conf. After each restart of systemd-resolved.service, SELinux prevents systemd-resolved from creating a symlink in /run/systemd/resolve/: type=AVC msg=audit(1605106378.670:735): avc: denied { create } for pid=29044 comm="systemd-resolve" name=".#stub-resolv.conf04abd1548d5fbff1" scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=lnk_file permissive=1 Version-Release number of selected component (if applicable): 3.14.6-29.fc33 How reproducible: Always; reproduced on 2 different hosts. Steps to Reproduce: 1. Set DNSStubListener=no in /etc/systemd/resolved.conf 2. ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf 3. systemctl restart systemd-resolved.service Actual results: SELinux prevents systemd-resolved from creating the symlink. Expected results: Systemd-resolved should be allowed to create symlinks in /run/systemd/resolve/.
I'm hitting this too, but you don't need to manually create the symlink yourself (systemd will handle that for you if not for this selinux bug). Starting from a pristine rawhide system (Fedora-Cloud-Base-Vagrant-Rawhide-20201205.n.0.x86_64.vagrant-libvirt.box): ``` [vagrant@vanilla-rawhide ~]$ ls -l /etc/resolv.conf lrwxrwxrwx. 1 root root 39 Dec 5 09:40 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf [vagrant@vanilla-rawhide ~]$ ls -lZ /var/run/systemd/resolve/ total 8 srw-rw-rw-. 1 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 0 Dec 7 21:35 io.systemd.Resolve drwx------. 2 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 60 Dec 7 21:36 netif -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 611 Dec 7 21:36 resolv.conf -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 738 Dec 7 21:36 stub-resolv.conf [vagrant@vanilla-rawhide ~]$ sudo mkdir /etc/systemd/resolved.conf.d [vagrant@vanilla-rawhide ~]$ echo -e '[Resolve]\nDNSStubListener=no' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf [Resolve] DNSStubListener=no [vagrant@vanilla-rawhide ~]$ sudo systemctl restart systemd-resolved [vagrant@vanilla-rawhide ~]$ [vagrant@vanilla-rawhide ~]$ sudo systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-12-07 21:37:04 UTC; 11s ago Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 3509 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 4640) Memory: 8.8M CPU: 122ms CGroup: /system.slice/systemd-resolved.service └─3509 /usr/lib/systemd/systemd-resolved Dec 07 21:37:04 vanilla-rawhide systemd[1]: Starting Network Name Resolution... Dec 07 21:37:04 vanilla-rawhide systemd-resolved[3509]: Positive Trust Anchors: Dec 07 21:37:04 vanilla-rawhide systemd-resolved[3509]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Dec 07 21:37:04 vanilla-rawhide systemd-resolved[3509]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa > Dec 07 21:37:04 vanilla-rawhide systemd-resolved[3509]: Using system hostname 'vanilla-rawhide'. Dec 07 21:37:04 vanilla-rawhide systemd-resolved[3509]: Failed to symlink /run/systemd/resolve/stub-resolv.conf: Permission denied Dec 07 21:37:04 vanilla-rawhide systemd[1]: Started Network Name Resolution. [vagrant@vanilla-rawhide ~]$ sudo ausearch -m avc | grep stub type=AVC msg=audit(1607377024.579:1031): avc: denied { create } for pid=3509 comm="systemd-resolve" name=".#stub-resolv.conf3b37f298db79c47a" scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=lnk_file permissive=0 ``` If selinux gets set to permissive mode then it works and this is what the resulting directory looks like: ``` [vagrant@vanilla-rawhide ~]$ ls -lZ /var/run/systemd/resolve/ total 4 srw-rw-rw-. 1 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 0 Dec 7 21:41 io.systemd.Resolve drwx------. 2 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 60 Dec 7 21:36 netif -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 611 Dec 7 21:41 resolv.conf lrwxrwxrwx. 1 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 11 Dec 7 21:41 stub-resolv.conf -> resolv.conf ``` Looks like we need to update something right around this line: https://github.com/fedora-selinux/selinux-policy/blob/6c7ec1db17385f4ac0c86f2e989868d70904cc68/policy/modules/system/systemd.te#L1082 My versions: ``` [vagrant@vanilla-rawhide ~]$ rpm -q selinux-policy-targeted systemd selinux-policy-targeted-3.14.7-10.fc34.noarch systemd-247.1-1.fc34.x86_64 ```
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/499
*** Bug 1898800 has been marked as a duplicate of this bug. ***
Backported to F33: https://github.com/fedora-selinux/selinux-policy/pull/500
FEDORA-2020-aff0be81b3 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3
Those pull requests don't seem to address the issue. I'm testing with selinux-policy-targeted-3.14.6-31.fc33.noarch. Can you attempt to reproduce the issue with the steps from comment#1 and verify you see the same thing I am?
FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-aff0be81b3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
OK, I tested the latest build in rawhide (selinux-policy-targeted-3.14.7-11.fc34.noarch) and it worked great. So something wrong with the backport?
FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
re-opening since selinux-policy-3.14.6-31.fc33 didn't have the patches needed for this bug
FEDORA-2020-f33aa1146d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f33aa1146d
FEDORA-2020-f33aa1146d has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f33aa1146d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f33aa1146d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-f33aa1146d has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.