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.