Bug 1953060 - SELinux is preventing systemd-hostnam from write access on the directory systemd
Summary: SELinux is preventing systemd-hostnam from write access on the directory systemd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1942205 1953799 1954993 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-23 19:34 UTC by Brandon Nielsen
Modified: 2021-10-19 02:30 UTC (History)
17 users (show)

Fixed In Version: selinux-policy-34.9-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-30 17:29:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
SELinux troubleshooter details (1.91 KB, text/plain)
2021-04-23 19:34 UTC, Brandon Nielsen
no flags Details
Denial log from XFCE aarch64 Fedora 34 disk image (1.11 KB, text/plain)
2021-04-30 01:00 UTC, Brandon Nielsen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1942205 1 medium CLOSED SELinux preventing systemd-hostnamed from unlinking /run/systemd/default-hostname 2021-05-18 17:31:37 UTC

Internal Links: 1966492

Description Brandon Nielsen 2021-04-23 19:34:45 UTC
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

Comment 1 Zdenek Pytela 2021-04-26 20:52:14 UTC
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

Comment 2 Zdenek Pytela 2021-04-27 10:17:13 UTC
*** Bug 1953799 has been marked as a duplicate of this bug. ***

Comment 3 Zdenek Pytela 2021-04-29 10:02:37 UTC
*** Bug 1954993 has been marked as a duplicate of this bug. ***

Comment 4 oli 2021-04-29 10:05:41 UTC
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

Comment 5 Zdenek Pytela 2021-04-29 10:28:42 UTC
(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.

Comment 6 oli 2021-04-29 10:43:27 UTC
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

Comment 7 Brandon Nielsen 2021-04-30 00:59:08 UTC
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

Comment 8 Brandon Nielsen 2021-04-30 01:00:30 UTC
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

Comment 9 Martin Pitt 2021-05-18 12:23:51 UTC
We started to see this in Cockpit's CI on most recent Fedora CoreOS: https://github.com/cockpit-project/bots/pull/2008

Comment 10 Zdenek Pytela 2021-05-18 17:31:12 UTC
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

Comment 11 Zdenek Pytela 2021-05-18 17:31:37 UTC
*** Bug 1942205 has been marked as a duplicate of this bug. ***

Comment 12 Fedora Update System 2021-05-28 21:17:41 UTC
FEDORA-2021-3a592334ef has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a592334ef

Comment 13 Fedora Update System 2021-05-29 01:51:22 UTC
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.

Comment 14 Fedora Update System 2021-05-30 17:29:19 UTC
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.

Comment 15 Hojat 2021-06-20 11:33:05 UTC
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

Comment 16 gpipili 2021-07-31 18:48:10 UTC
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

Comment 17 Randy Jones 2021-08-16 00:14:24 UTC
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


Note You need to log in before you can comment on or make changes to this bug.