Bug 1970865

The permission was found missing in RHEL 9 by CI tests.

+++ This bug was initially created as a clone of Bug #1949315 +++

Description of problem:

systemd-timesyncd fails to start on boot after upgrade to Fedora 34.

Apr 14 02:32:08 polaris systemd[1]: Starting systemd-timesyncd.service...
Apr 14 02:32:08 polaris systemd-timesyncd[1138]: Failed to connect to bus: Permission denied
Apr 14 02:32:08 polaris systemd-timesyncd[1138]: Could not connect to bus: Permission denied
Apr 14 02:32:08 polaris systemd[1]: systemd-timesyncd.service: Main process exited, code=exited, status=1/FAILURE
Apr 14 02:32:08 polaris systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Apr 14 02:32:08 polaris systemd[1]: Failed to start systemd-timesyncd.service.
Apr 14 02:32:08 polaris audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Apr 14 02:32:08 polaris systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 5.
Apr 14 02:32:08 polaris systemd[1]: Stopped systemd-timesyncd.service.
Apr 14 02:32:08 polaris audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 14 02:32:08 polaris audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 14 02:32:08 polaris systemd[1]: systemd-timesyncd.service: Start request repeated too quickly.
Apr 14 02:32:08 polaris systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Apr 14 02:32:08 polaris systemd[1]: Failed to start systemd-timesyncd.service.


SELinux is preventing systemd-timesyn from watch access on the directory /.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that systemd-timesyn should be allowed watch access on the  directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'systemd-timesyn' --raw | audit2allow -M my-systemdtimesyn
# semodule -X 300 -i my-systemdtimesyn.pp

Additional Information:
Source Context                system_u:system_r:systemd_timedated_t:s0
Target Context                system_u:object_r:root_t:s0
Target Objects                / [ dir ]
Source                        systemd-timesyn
Source Path                   systemd-timesyn
Port                          <Unknown>
Host                          polaris
Source RPM Packages           
Target RPM Packages           filesystem-3.14-5.fc34.x86_64
SELinux Policy RPM            selinux-policy-targeted-34.3-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.3-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     polaris
Platform                      Linux polaris 5.11.13-300.fc34.x86_64 #1 SMP Sun
                              Apr 11 15:07:42 UTC 2021 x86_64 x86_64
Alert Count                   4
First Seen                    2021-04-14 02:32:08 CEST
Last Seen                     2021-04-14 02:32:08 CEST
Local ID                      19553ffe-61f6-460a-abdd-229c165550aa

Raw Audit Messages
type=AVC msg=audit(1618360328.663:158): avc:  denied  { watch } for  pid=1138 comm="systemd-timesyn" path="/" dev="dm-0" ino=2 scontext=system_u:system_r:systemd_timedated_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0


Hash: systemd-timesyn,systemd_timedated_t,root_t,dir,watch


Version-Release number of selected component (if applicable):

selinux-policy-34.3-1.fc34.noarch

How reproducible:
Always on boot but seems to work without warnings if started manually after boot is finished.

Steps to Reproduce:
Boot Fedora 34.

Actual results:
systemd-timesyncd fails to start on boot.

Expected results:
Successful systemd-timesyncd start.

--- Additional comment from Zdenek Pytela on 2021-04-14 09:01:50 CEST ---

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/693

--- Additional comment from Milos Malik on 2021-04-14 09:42:42 CEST ---

The same issue is reproducible on RHEL-9 during reboot:
----
type=PROCTITLE msg=audit(04/14/2021 09:25:32.175:147) : proctitle=/usr/lib/systemd/systemd-timesyncd 
type=PATH msg=audit(04/14/2021 09:25:32.175:147) : item=0 name=/ inode=128 dev=fd:02 mode=dir,555 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:root_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(04/14/2021 09:25:32.175:147) : cwd=/ 
type=SYSCALL msg=audit(04/14/2021 09:25:32.175:147) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0xb a1=0x7feef3276d6f a2=0x180 a3=0x7ffc26abbb84 items=1 ppid=1 pid=611 auid=unset uid=systemd-timesync gid=systemd-timesync euid=systemd-timesync suid=systemd-timesync fsuid=systemd-timesync egid=systemd-timesync sgid=systemd-timesync fsgid=systemd-timesync tty=(none) ses=unset comm=systemd-timesyn exe=/usr/lib/systemd/systemd-timesyncd subj=system_u:system_r:systemd_timedated_t:s0 key=(null) 
type=AVC msg=audit(04/14/2021 09:25:32.175:147) : avc:  denied  { watch } for  pid=611 comm=systemd-timesyn path=/ dev="vda2" ino=128 scontext=system_u:system_r:systemd_timedated_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0 
----

Normal start/restart/stop of the service does not reproduce it.

--- Additional comment from Milos Malik on 2021-04-14 17:52:35 CEST ---

Test coverage for this bug exists in a form of PR:
 * https://src.fedoraproject.org/tests/selinux/pull-request/207

The PR waits for review.

--- Additional comment from Fedora Update System on 2021-04-27 21:56:51 CEST ---

FEDORA-2021-8d26207af7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d26207af7

--- Additional comment from Fedora Update System on 2021-04-28 03:35:22 CEST ---

FEDORA-2021-8d26207af7 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-8d26207af7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d26207af7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

--- Additional comment from Fedora Update System on 2021-05-04 03:00:51 CEST ---

FEDORA-2021-8d26207af7 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.