Created attachment 1774918 [details] SELinux troubleshooter details Description of problem: XFCE shows "SELinux is preventing systemd-hostnam from write access on the directory systemd" SELinux denial on boot Version-Release number of selected component (if applicable): Tested with XFCE armhfp and aarch64 F34 RC 1.2 How reproducible: Every time. Steps to Reproduce: 1. Write disk image 2. Boot 3. Observe error Actual results: SELinux troubleshooter reports "SELinux is preventing systemd-hostnam from write access on the directory systemd". Expected results: No SELinux denials on boot. Additional info: Tested with both armhfp[0] and aarch64[1] composes. I have attached the troubleshooter details. [0] - https://kojipkgs.fedoraproject.org/compose/34/Fedora-34-20210423.0/compose/Spins/armhfp/images/Fedora-Xfce-34-1.2.armhfp.raw.xz [1] - https://kojipkgs.fedoraproject.org/compose/34/Fedora-34-20210423.0/compose/Spins/aarch64/images/Fedora-Xfce-34-1.2.aarch64.raw.xz
Brandon, Will you be able to collect denials with full auditing enabled? 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario and reboot if it is required. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot
*** Bug 1953799 has been marked as a duplicate of this bug. ***
*** Bug 1954993 has been marked as a duplicate of this bug. ***
i followed your guide but did not reboot in step 5 but reproduced the error (hope a reboot is not required) [root@lucy oli]# hostnamectl set-hostname lucy [root@lucy oli]# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot ---- type=AVC msg=audit(29.04.2021 10:07:25.461:525) : avc: denied { write } for pid=5475 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 ---- type=AVC msg=audit(29.04.2021 10:36:17.293:697) : avc: denied { write } for pid=28185 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 ---- type=PROCTITLE msg=audit(29.04.2021 12:04:43.996:841) : proctitle=/usr/lib/systemd/systemd-hostnamed type=PATH msg=audit(29.04.2021 12:04:43.996:841) : item=1 name=/run/systemd/default-hostname inode=12 dev=00:1a mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=DELETE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(29.04.2021 12:04:43.996:841) : item=0 name=/run/systemd/ inode=2 dev=00:1a mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(29.04.2021 12:04:43.996:841) : cwd=/ type=SYSCALL msg=audit(29.04.2021 12:04:43.996:841) : arch=x86_64 syscall=unlink success=no exit=EACCES(Keine Berechtigung) a0=0x7fa0e2426945 a1=0x0 a2=0x7fa0e2426fb7 a3=0x7fa0e217d3e0 items=2 ppid=1 pid=35302 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-hostnam exe=/usr/lib/systemd/systemd-hostnamed subj=system_u:system_r:systemd_hostnamed_t:s0 key=(null) type=AVC msg=audit(29.04.2021 12:04:43.996:841) : avc: denied { write } for pid=35302 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
(In reply to oli from comment #4) > i followed your guide but did not reboot in step 5 but reproduced the error > (hope a reboot is not required) Reboot is not required if it reproduced, thank you for the audit records. I cannot reproduce it, I wonder which conditions are needed.
thats a fresh install of fedora 34 mate the only thing i did was: add rpmfusion, install vlc and kmod-nvidia everything else is regular if i can help you in any way, just let me know and i'll try my best
I can also reproduce the issue just booting (not installing) an XFCE Live ISO[0] in virtual machine. In that case the issue does not persist through to the install. I cannot reproduce with a current rawhide XFCE compose. The issue I originally reported in the description only appears on the first boot so it required some jiggery pokery of the disk image to capture the requested log. It matches that from the log in comment 4, but I will attach it anyway. [0] - https://kojipkgs.fedoraproject.org/compose/34/Fedora-34-20210423.0/compose/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-34-1.2.iso
Created attachment 1777527 [details] Denial log from XFCE aarch64 Fedora 34 disk image Audit log from first boot of Fedora-Xfce-34-1.2.aarch64.raw.xz
We started to see this in Cockpit's CI on most recent Fedora CoreOS: https://github.com/cockpit-project/bots/pull/2008
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/746 While still unable to reproduce directly, I gathered the following information. AVCs in permissive mode (bz#1942205) 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 All audit records for the first event: ---- type=PROCTITLE msg=audit(04/29/2021 19:47:29.192:307) : proctitle=/usr/lib/systemd/systemd-hostnamed type=PATH msg=audit(04/29/2021 19:47:29.192:307) : item=0 name=/run/systemd/ inode=2 dev=00:1c mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(04/29/2021 19:47:29.192:307) : cwd=/ type=SYSCALL msg=audit(04/29/2021 19:47:29.192:307) : arch=aarch64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffffffffffff9c a1=0xaaaaf93ecba0 a2=O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC a3=0x180 items=1 ppid=1 pid=1277 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-hostnam exe=/usr/lib/systemd/systemd-hostnamed subj=system_u:system_r:systemd_hostnamed_t:s0 key=(null) type=AVC msg=audit(04/29/2021 19:47:29.192:307) : avc: denied { write } for pid=1277 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 The only place in systemd source 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
*** Bug 1942205 has been marked as a duplicate of this bug. ***
FEDORA-2021-3a592334ef has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a592334ef
FEDORA-2021-3a592334ef has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3a592334ef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a592334ef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3a592334ef has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Similar problem has been detected: hang on boot or cpu hight hashmarkername: setroubleshoot kernel: 5.11.12-300.fc34.x86_64 package: selinux-policy-targeted-34-1.fc34.noarch reason: SELinux is preventing systemd-hostnam from 'write' accesses on the directory systemd. type: libreport
Similar problem has been detected: After trying to install Fedora34 six times, I could not get my install to boot. This installation is on an SSD on a AMD 2700x machine. How to fix the booting on my computer? hashmarkername: setroubleshoot kernel: 5.11.12-300.fc34.x86_64 package: selinux-policy-targeted-34-1.fc34.noarch reason: SELinux is preventing systemd-hostnam from 'write' accesses on the directory systemd. type: libreport
Similar problem has been detected: i dont really know hashmarkername: setroubleshoot kernel: 5.11.12-300.fc34.x86_64 package: selinux-policy-targeted-34-1.fc34.noarch reason: SELinux is preventing systemd-hostnam from 'write' accesses on the directory systemd. type: libreport