Description of problem: Mar 23 20:09:31 cosa-devsh audit[945]: AVC avc: denied { write } for pid=945 comm="systemd-hostnam" name="systemd" dev="tmpfs" ino=2 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=0 ... Mar 23 20:09:31 cosa-devsh systemd-hostnamed[945]: Failed to remove "/run/systemd/default-hostname": Permission denied Version-Release number of selected component (if applicable): # rpm -q systemd selinux-policy systemd-248~rc4-2.fc34.x86_64 selinux-policy-3.14.7-25.fc34.noarch How reproducible: 100% Steps to Reproduce: 1. Boot a Fedora 34-based system like FCOS on the branched stream (https://builds.coreos.fedoraproject.org/browser?stream=branched) with e.g. hostname via DHCP (e.g. libvirt) Actual results: systemd-hostnamed fails to remove `/run/systemd/default-hostname` Expected results: systemd-hostnamed successfully removes `/run/systemd/default-hostname` Additional info: This file is new in Fedora 34 systemd, introduced in https://github.com/systemd/systemd/pull/18704.
Actually, I see three separate AVC denials related to this: Mar 23 21:12:53 cosa-devsh audit[707]: AVC avc: denied { write } for pid=707 comm="systemd-hostnam" name="systemd" dev="tmpfs" ino=2 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=1 Mar 23 21:12:53 cosa-devsh audit[707]: AVC avc: denied { remove_name } for pid=707 comm="systemd-hostnam" name="default-hostname" dev="tmpfs" ino=12 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=1 Mar 23 21:12:53 cosa-devsh audit[707]: AVC avc: denied { unlink } for pid=707 comm="systemd-hostnam" name="default-hostname" dev="tmpfs" ino=12 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
Jonathan, Thank you for the detailed report, needs to be addressed. In permissive mode, all denials are audited; in this case all three are required for the file removal.
Hi Zdenek, Have you had a chance to look at this yet? We're still hitting this in FCOS 34 and while it doesn't seem to cause any adverse effects, we'd like to avoid triggering any SELinux denials at all for the f34 rebase.
*** Bug 1951710 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Lebon from comment #3) > Hi Zdenek, > > Have you had a chance to look at this yet? We're still hitting this in FCOS > 34 and while it doesn't seem to cause any adverse effects, we'd like to > avoid triggering any SELinux denials at all for the f34 rebase. Jonathan, Sorry for the delay, the issue will be addressed soon. If it's urgent, I can dontaudit it right away even if later we could find another solution. This seems to be the only place in systemd where default-hostname is being written to or removed: src/shared/hostname-setup.c 148 void hostname_update_source_hint(const char *hostname, HostnameSource source) { 149 int r; 150 151 /* Why save the value and not just create a flag file? This way we will 152 * notice if somebody sets the hostname directly (not going through hostnamed). 153 */ 154 155 if (source == HOSTNAME_DEFAULT) { 156 r = write_string_file("/run/systemd/default-hostname", hostname, 157 WRITE_STRING_FILE_CREATE | WRITE_STRING_FILE_ATOMIC); 158 if (r < 0) 159 log_warning_errno(r, "Failed to create \"/run/systemd/default-hostname\ ": %m"); 160 } else 161 unlink_or_warn("/run/systemd/default-hostname"); 162 } 163 but the file can be created by other processes. There seems to be no problem than the AVC denial and possibly an error message.
> There seems to be no problem than the AVC denial and possibly an error message. I think it can cause issues for services querying systemd-hostnamed to find out the source of the hostname. This file is used to determine the HostnameSource D-Bus property (https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html). That said, it's a rather new property and I don't think anything is actually relying on it yet. > Sorry for the delay, the issue will be addressed soon. If it's urgent, I can dontaudit it right away even if later we could find another solution. It's not super urgent, but it'd be really nice if we shipped Fedora 34 in the `stable` stream without any SELinux denials. This would ideally mean having a fix into next week's `testing` release.
There is more information now in bz#1953060, continuing there. *** This bug has been marked as a duplicate of bug 1953060 ***