Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1471545
Summary: | SElinux prevents postfix from reading /run/systemd/resolve/resolv.conf | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mathieu Chouquet-Stringer <mathieu-acct> |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 27 | CC: | accounts+fedora, amessina, bugzilla.redhat, dominick.grift, dwalsh, lvrabec, mathieu-acct, mgrepl, msekleta, paul.destefano-redhat2, plautrba, pmoore, ssekidde, thilo.bangert, thomas |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | selinux-policy-3.13.1-283.28.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-03-23 13:20:47 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mathieu Chouquet-Stringer
2017-07-16 19:48:01 UTC
Mathieu, Label of /run/systemd/resolve/resolv.conf shoudl be net_conf_t. On your system label of /run/systemd/resolve/resolv.conf is systemd_resolved_var_run_t. This is not good. Could you restore labels on /run/systmed/resolve using following command: # restorecon -Rv /run/systemd/ and then try to reproduce the issue? Thanks, Lukas. Hello Lukas, Yes restorecon changed the label but then I had done a full relabeling on boot before. # restorecon -Rv /run/systemd/ Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 If I reboot the box in question: %ls -lZ /run/systemd/resolve/resolv.conf -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:systemd_resolved_var_run_t:s0 549 Jul 20 22:56 /run/systemd/resolve/resolv.conf Not sure what's going on (and sure enough restorecon fixes it again but it doesn't solve the problem). If I do semanage fcontext -l | fgrep /resolve, I do get net_conf_t: /var/run/systemd/resolve(/.*)? all files system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv\.conf regular file system_u:object_r:net_conf_t:s0 To make sure it wasn't an old local module messing with that, I even removed selinux-policy and selinux-policy-targeted, then remove /etc/selinux/targeted before reinstalling, relabeling and enabline selinux again. Same result... I also have this issue which affects a whole host of daemons (all that require access to /etc/resolv.conf) Same here with chronyd, abrt-action-sav, cupsd, httpd... They all complain that "/run/systemd/resolve/resolv.conf default label should be net_conf_t." /run/systemd/resolve/resolv.conf is maintained by systemd-resolved selinux-policy-3.13.1-260.4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-323fb6bb66 selinux-policy-3.13.1-260.4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-323fb6bb66 selinux-policy-3.13.1-260.4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Problem still persists with selinux-policy-3.13.1-260.4.fc26.noarch In my case, it is php-fpm, which is prevented from reading resolv.conf: AVC avc: denied { read } for pid=1415 comm="php-fpm" name="resolv.conf" dev="tmpfs" ino=85410 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=file permissive=0 I also experience this problem - have just today updated from f25. Please reopen as the selinux-policy update did not fix this issue. selinux-policy-3.13.1-260.8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fd93b6e5f8 selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fd93b6e5f8 selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. still a problem AFAICT (In reply to Fedora Update System from comment #13) > selinux-policy-3.13.1-260.8.fc26 has been pushed to the Fedora 26 stable > repository. If problems still persist, please make note of it in this bug > report. The above update did not fix the issue of /run/systemd/resolve/resolv.conf getting the wrong label (system_u:object_r:systemd_resolved_var_run_t:s0). After boot, /run/systemd/resolve/resolv.conf is labeled with system_u:object_r:systemd_resolved_var_run_t:s0. Even after restorecon which does properly change the label to system_u:object_r:net_conf_t:s0, when restarting systemd-resolved, /run/systemd/resolve/resolv.conf is (re)labeled with system_u:object_r:systemd_resolved_var_run_t:s0. Please reopen. see also bug #1486567 which I opened as this bug wasn't reopened... selinux-policy-3.13.1-260.9.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0cf00e6f4e selinux-policy-3.13.1-260.9.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0cf00e6f4e selinux-policy-3.13.1-260.9.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. problem still apears with selinux-policy-3.13.1-260.9.fc26 ls -Z /run/systemd/resolve/resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0 /run/systemd/resolve/resolv.conf ls -Z /var/run/systemd/resolve/resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv.conf semanage fcontext -l |grep resolv /etc/\.resolv\.conf.* all files system_u:object_r:net_conf_t:s0 /etc/ppp/resolv\.conf regular file system_u:object_r:pppd_etc_rw_t:s0 /etc/resolv-secure.conf.* all files system_u:object_r:net_conf_t:s0 /etc/resolv\.conf.* all files system_u:object_r:net_conf_t:s0 /etc/sysconfig/network-scripts/.*resolv\.conf regular file system_u:object_r:net_conf_t:s0 /usr/lib/policykit/polkit-resolve-exe-helper.* regular file system_u:object_r:policykit_resolve_exec_t:s0 /usr/lib/systemd/resolv.* regular file system_u:object_r:lib_t:s0 /usr/lib/systemd/system/systemd-resolved\.service all files system_u:object_r:systemd_resolved_unit_file_t:s0 /usr/lib/systemd/systemd-resolve(d|-host) all files system_u:object_r:systemd_resolved_exec_t:s0 /usr/libexec/polkit-resolve-exe-helper.* regular file system_u:object_r:policykit_resolve_exec_t:s0 /var/run/NetworkManager/resolv\.conf.* regular file system_u:object_r:net_conf_t:s0 /var/run/systemd/resolve(/.*)? all files system_u:object_r:systemd_resolved_var_run_t:s0 /var/run/systemd/resolve/resolv.conf all files system_u:object_r:net_conf_t:s0 /var/run/systemd/resolve/resolv\.conf regular file system_u:object_r:net_conf_t:s0 Hi Lukas. This ticket keeps getting closed with each new selinux-policy release for F26, but in reviewing the diff between the changes made upstream and in -contrib, I can't seem to find that any of the changes were even remotely related to this problem. Is there something specific I'm missing in the upstream changes? Or perhaps is this something that needs to go upstream to systemd since even after the files are labeled appropriately, a restart of systemd-resolved reverts the file context to systemd_resolved_var_run_t? This should be fixed by something like: https://github.com/fedora-selinux/selinux-policy/pull/202 You could try it out by installing the following policy. #======================== cut ============================================= policy_module(mysystemd, 1.0) gen_require(` type systemd_resolved_t, systemd_resolved_var_run_t; ') sysnet_filetrans_config_fromdir(systemd_resolved_t,systemd_resolved_var_run_t, file, "resolv.conf") sysnet_filetrans_config_fromdir(systemd_resolved_t,systemd_resolved_var_run_t, file, "resolv.conf.tmp") #======================================================================== make -f /usr/share/selinux/devel/Makefile semodule -i mysystemd selinux-policy-3.13.1-260.10.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-29d4eac4a8 selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-29d4eac4a8 selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. (In reply to Fedora Update System from comment #25) > selinux-policy-3.13.1-260.10.fc26 has been pushed to the Fedora 26 stable > repository. If problems still persist, please make note of it in this bug > report. Unfortunately, this was not fixed with selinux-policy-3.13.1-260.10.fc26. Could someone with the right permissions reopen this bug, please? selinux-policy-3.13.1-260.12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce selinux-policy-3.13.1-260.12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce selinux-policy-3.13.1-260.13.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce selinux-policy-3.13.1-260.13.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-88b6a06bce selinux-policy-3.13.1-260.13.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Problem still persists with 3.13.1-260.13.fc26 : read access denied on /run/systemd/resolve/resolv.conf for chronyd, cupsd, httpd still an issue. solvable (until next boot) with [bangert@stuart ~]$ sudo restorecon -Rv /run/systemd/ [sudo] password for bangert: Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 steps to reproduce : fresh install upgrade systemctl disable NetworkManager.service systemctl enable systemd-networkd.service systemd-resolved.service reboot ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf This issue still occurs with F27. Please reopen. What is going on? Hasn't systemd-networkd been supported for a long time? I don't understand how this is still an issue. Problem is still present... Guys, Are you still have this issue with the latest selinux-policy builds? Thanks, Lukas. As the system is not usable in the broken configuration (i.e. systemd-resolved in second mode where /etc/resolv.conf is a symlink), I would have to change my system configuration to tell, for sure right now. If you can wait, I'll try it later. However, since /run/systemd/resolve/resolv.conf still has the wrong label, I doubt it is fixed. There is a note in selinux-policy changelog that says this specifically was corrected, but it doesn't seem like it worked. $ sudo -i restorecon -v /run/systemd/resolve/resolv.conf Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 This continues to be an issue in F27 builds. I think in another ticket you indicated the issue was resolved in a rawhide VM, so I've been waiting a bit. However in F27, the issue is persistent despite the file context labels in /etc/selinux/targeted/contexts/files being correct. Is there some upstream issue here when systemd itself is relabeling the file--it happens after each restart of systemd-networkd or if a new dhcp lease is obtained. Michal, Systemd-resolved is renaming stub-resolv.conf to resolv.conf in /run/systemd/resolve/resolv.conf ? For some reason we have resolv.conf labeled as systemd_resolved_var_run_t instead of net_conf_t but I see stub-resolv.conf in "resolve" directory. This renaming can cause this issue. I added fixes that systemd_resolved_t can create stub-resolv.conf as net_conf_t label. Please let me know if my assumptions are right. Thanks, Lukas. (In reply to Lukas Vrabec from comment #42) > Michal, > > Systemd-resolved is renaming stub-resolv.conf to resolv.conf in > /run/systemd/resolve/resolv.conf ? No, these are two distinct files. /run/systemd/resolve/resolv.conf contains list of uplink DNS servers (provided by DHCP server usually) while /run/systemd/resolve/stub-resolv.conf containst only one nameserver entry pointing to local stub resolver on 127.0.0.53. > For some reason we have resolv.conf labeled as systemd_resolved_var_run_t > instead of net_conf_t but I see stub-resolv.conf in "resolve" directory. > This renaming can cause this issue. systemd-resolved takes care of labeling by looking up paths in selinux-policy before it creates temp files. IOW, temp files have labels according to policy. [root@localhost ~]# ls -lZ /run/systemd/resolve/.#resolv.confp3sG7G -rw-r--r--. 1 systemd-resolve systemd-resolve system_u:object_r:net_conf_t:s0 0 Mar 1 18:02 /run/systemd/resolve/.#resolv.confp3sG7G > > I added fixes that systemd_resolved_t can create stub-resolv.conf as > net_conf_t label. > Please let me know if my assumptions are right. That should fix the issue. However, I still see wrong file context in rawhide, [root@localhost ~]# rpm -q selinux-policy selinux-policy-3.14.2-2.fc29.noarch [root@localhost ~]# matchpathcon /run/systemd/resolve/stub-resolv.conf /run/systemd/resolve/stub-resolv.conf system_u:object_r:systemd_resolved_var_run_t:s0 Fixed. Thanks. selinux-policy-3.13.1-283.28.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-32ebae3424 selinux-policy-3.13.1-283.28.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-32ebae3424 I just updated my policy to the one from bodhi and same thing: %uptime 21:11:36 up 8 min, 1 user, load average: 0.63, 1.15, 0.82 %rpm -qa selinux\* selinux-policy-3.13.1-283.28.fc27.noarch selinux-policy-targeted-3.13.1-283.28.fc27.noarch %sudo restorecon -v /run/systemd/resolve/resolv.conf Relabeled /run/systemd/resolve/resolv.conf from system_u:object_r:systemd_resolved_var_run_t:s0 to system_u:object_r:net_conf_t:s0 So I'm afraid the problem is still present selinux-policy-3.13.1-283.28.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-32ebae3424 worked around with: cp /usr/lib/systemd/system/systemd-resolved.service /etc/systemd/system/systemd-resolved.service Changed "ReadWritePaths" parameter with: ReadWritePaths=/run/systemd /var/run/systemd/system in /etc/systemd/system/systemd-resolved.service (In reply to Zachary Elcor from comment #49) > worked around with: > > cp /usr/lib/systemd/system/systemd-resolved.service > /etc/systemd/system/systemd-resolved.service > > Changed "ReadWritePaths" parameter with: > > ReadWritePaths=/run/systemd /var/run/systemd/system > > in /etc/systemd/system/systemd-resolved.service Zachary when you say "worked around with..." do you mean that the resolv.conf file is labeled correctly as system_u:object_r:net_conf_t:s0 or do you mean that with the file is then readable with SELinux enforcing? In permissive mode, and your workaround applied, I still show resolv.conf labeled with system_u:object_r:systemd_resolved_var_run_t:s0 after a relabel/reboot or after a relabel and restart of systemd-resolved.service. This is with selinux-policy-targeted-3.13.1-283.28.fc27.noarch (In reply to comment #50) With workaround from comment #49, I now have /run/systemd/resolve/resolv.conf labeled as system_u:object_r:net_conf_t:s0 selinux-policy-targeted-3.13.1-283.26.fc27.noarch with Enforcing mode selinux-policy-3.13.1-283.28.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. Reopening because the new selinux policy didn't fix it. *** This bug has been marked as a duplicate of bug 1556862 *** bug #1556862 appears to be locked -- access denied. |