Description of problem: This just began appearing after upgrade to F33, I do not know why, but I'm getting it a few times a day ... SELinux is preventing chronyd from 'read' accesses on the soubor wlp4s0.sources. ***** Plugin catchall (100. confidence) suggests ************************** Pokud jste přesvědčeni, že má chronyd mít ve výchozím stavu přístup read na wlp4s0.sources file. Then měli byste tento problém nahlásit jako chybu. Abyste přístup povolili, můžete vygenerovat lokální modul pravidel. Do prozatím tento přístup povolíte příkazy: # ausearch -c 'chronyd' --raw | audit2allow -M my-chronyd # semodule -X 300 -i my-chronyd.pp Additional Information: Source Context system_u:system_r:chronyd_t:s0 Target Context system_u:object_r:initrc_var_run_t:s0 Target Objects wlp4s0.sources [ file ] Source chronyd Source Path chronyd Port <Neznámé> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM <Neznámé> Local Policy RPM selinux-policy-targeted-3.14.6-27.fc33.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.8.9-301.fc33.x86_64 #1 SMP Mon Sep 14 19:30:07 UTC 2020 x86_64 x86_64 Alert Count 2 First Seen 2020-09-21 10:24:33 CEST Last Seen 2020-09-21 10:24:33 CEST Local ID d85e431d-6724-4bff-8441-8988db60e57a Raw Audit Messages type=AVC msg=audit(1600676673.810:75540): avc: denied { read } for pid=994 comm="chronyd" name="wlp4s0.sources" dev="tmpfs" ino=2165454 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 Hash: chronyd,chronyd_t,initrc_var_run_t,file,read Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.8.9-301.fc33.x86_64 type: libreport
Can you find out where is the wlp4s0.sources file located? # find / -inum 2165454 Thank you.
(In reply to Milos Malik from comment #1) > Can you find out where is the wlp4s0.sources file located? > > # find / -inum 2165454 > > Thank you. this doesn't work (yes, I also took the ino from the most recent error I got), however searching by name, I see this one: # ls -lZ /run/chrony-dhcp/wlp4s0.sources -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 29 21. zář 16.55 /run/chrony-dhcp/wlp4s0.sources
ok, looks like the file gets deleted/recreated periodically, and the error happens right after the file gets created I just got the report at 09:25:34, and seraching immediately, I see the file time 9:25 - [root@kvolny ~]# find / -inum 5503764 /run/chrony-dhcp/wlp4s0.sources find: ‘/run/user/1000/doc’: Operace zamítnuta find: ‘/proc/571956/task/571956/net’: Nepřípustný argument find: ‘/proc/571956/net’: Nepřípustný argument [root@kvolny ~]# ls -lZ /run/chrony-dhcp/wlp4s0.sources -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 29 22. zář 09.25 /run/chrony-dhcp/wlp4s0.sources [root@kvolny ~]# cat /run/chrony-dhcp/wlp4s0.sources server 10.192.206.245 iburst
Karle, There certainly is something to adjust in the selinux policy. I noticed you reported not being aware why, but still can you somehow help to isolate the problem? Is there something special/non-default in your environment? What additionally confuses me a bit is the type of /run/chrony-dhcp/wlp4s0.sources: it should be just var_run_t (which is incorrect anyway), according to current rules. Did you run chcon/restorecon on the directory, the semanage-fcontext command, or created a custom policy module? # ls -laZ /run/chrony-dhcp/ We have an unnamed transition for a file only though in the policy: # sesearch -T -s NetworkManager_t -t NetworkManager_initrc_exec_t -c process type_transition NetworkManager_t NetworkManager_initrc_exec_t:process initrc_t; # sesearch -T -s initrc_t -t var_run_t | grep "_t;" type_transition initrc_t var_run_t:file initrc_var_run_t; # sesearch -T -s initrc_t -t var_run_t | grep chrony <>
(In reply to Zdenek Pytela from comment #4) > There certainly is something to adjust in the selinux policy. I noticed you > reported not being aware why, but still can you somehow help to isolate the > problem? Is there something special/non-default in your environment? well, I believe the answer to "non-default" probably lies in the initial description - this is not a clean installation but rather an upgrade, and there are always problems with upgrades ;-) I've used msuchy's fedora-upgrade with the online method, which isn't the one preferred ... > What additionally confuses me a bit is the type of > /run/chrony-dhcp/wlp4s0.sources: it should be just var_run_t (which is > incorrect anyway), according to current rules. Did you run chcon/restorecon > on the directory, the semanage-fcontext command, or created a custom policy > module? no, I haven't done anything special > # ls -laZ /run/chrony-dhcp/ [root@kvolny ~]# ls -laZ /run/chrony-dhcp/ celkem 8 drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 80 24. zář 14.08 . drwxr-xr-x. 49 root root system_u:object_r:var_run_t:s0 1260 24. zář 09.10 .. -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 50 24. zář 09.08 ens1u1.sources -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 29 24. zář 14.08 wlp4s0.sources running sesearch queries, the same results on my system
SELinux is preventing chronyd from read access on the file wlp3s0.sources. Plugin catchall (100. confidence) suggests If you believe that chronyd should be allowed read access on the wlp3s0.sources file 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 'chronyd' --raw | audit2allow -M my-chronyd semodule -X 300 -i my-chronyd.pp sudo ausearch -c 'chronyd' time->Fri Sep 25 08:09:14 2020 type=AVC msg=audit(1601014154.941:198): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.370:274): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.390:276): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.586:296): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.606:297): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.084:187): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.784:262): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.807:264): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.929:284): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0 time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.948:285): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0
I can confirm what Christian Labisch reported
Upgraded to selinux-policy 3.14.6-28.fc33 ... nothing changed - getting the same messages. The alerts appear after booting and logging in, and also after starting a virtual machine.
Similar problem has been detected: Happened randomly in background hashmarkername: setroubleshoot kernel: 5.8.11-300.fc33.x86_64 package: selinux-policy-targeted-3.14.6-27.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the Datei enp3s0.sources. type: libreport
Similar problem has been detected: This appeared after upgrade from F32 to F33 with updates-testing enabled on Oct 7th. My DHCP server hands out NTP servers if that's relevant. hashmarkername: setroubleshoot kernel: 5.8.13-300.fc33.x86_64 reason: SELinux is preventing chronyd from 'read' accesses on the file wlp1s0.sources. type: libreport
Same problem here with a freshly installed and updated (today) Fedora 33. Time never gets udpated because of this bug. Just to be sure, I did a `sudo setenforce 0`, followed by disabling/enabling the feature in the control center, and this time chrony managed to update my clock correctly.
Similar problem has been detected: This happens every time I boot the machine. I suppose it might be in the context of bringing up the network interface. hashmarkername: setroubleshoot kernel: 5.8.14-300.fc33.x86_64 package: selinux-policy-targeted-3.14.6-28.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the Datei ens1u2u1u2.sources. type: libreport
Similar problem has been detected: Alter appeared randomly in background hashmarkername: setroubleshoot kernel: 5.8.13-300.fc33.x86_64 package: selinux-policy-targeted-3.14.6-28.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the Datei enp3s0.sources. type: libreport
Proposed as a Freeze Exception for 33-final by Fedora user dustymabe using the blocker tracking app because: It would be nice to be able to get NTP server's from DHCP for Fedora 33.
Does this problem have any consequences for chrony functionality, can somebody check? If you disable NTP, change the system time and then enable NTP again, will it sync to the proper time? (I think that's how this is supposed to work). With SELinux enforcing, of course.
(In reply to Kamil Páral from comment #15) > Does this problem have any consequences for chrony functionality, can > somebody check? If you disable NTP, change the system time and then enable > NTP again, will it sync to the proper time? (I think that's how this is > supposed to work). With SELinux enforcing, of course. I think this depends on the user's environment. This bug causes NTP servers provided by their DHCP server to not get applied. If they have access to the public internet then they will probably still get a correct time setting, though with servers that aren't preferred. If they don't have access to the public internet then they could get no NTP server at all.
I've submitted rawhide PRs to address the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/344 https://github.com/fedora-selinux/selinux-policy/pull/456
+5 votes in https://pagure.io/fedora-qa/blocker-review/issue/173 , marking as accepted. Zdenek, can you backport to F33 and do a build/update for F33?
Surely I'll backport the PRs (if accepted) to F33 and create builds so that it can be tested in different scenarios/environments as I cannot make sure the suggested fix is complete and covers all possible usage.
I'll be happy to test once a build is available for F33. We have a test that runs in the Fedora CoreOS build pipeline that will tell us if it's working.
A scratchbuild is available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=53505109
(In reply to Zdenek Pytela from comment #21) > A scratchbuild is available here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=53505109 That's selinux-policy-3.14.6-24.200.bz1880948.fc33, but the latest build for F33 is selinux-policy-3.14.6-28.fc33 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1617771). So, technically, this is a downgrade.
That scratch build passes the test.
Similar problem has been detected: SELinux errors on default install of Fedora 33 beta. hashmarkername: setroubleshoot kernel: 5.8.15-301.fc33.x86_64 package: selinux-policy-targeted-3.14.6-28.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the file enp0s31f6.sources. type: libreport
FEDORA-2020-5cd3fad6d5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5cd3fad6d5
selinux-policy 3.14.6-29.fc33 solved the problem ... thank you, Zdenek !
FEDORA-2020-5cd3fad6d5 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
Similar problem has been detected: Happend right after switching to another WiFi AP. hashmarkername: setroubleshoot kernel: 5.10.7-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-34.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the file wlp1s0.sources. type: libreport
This just appeared after selinux-policy-targeted-3.14.6-33.fc33_3.14.6-34.fc33.noarch.drpm / selinux-policy-targeted-3.14.6-34.fc33.noarch
*** Bug 1917515 has been marked as a duplicate of this bug. ***
*** Bug 1877629 has been marked as a duplicate of this bug. ***
Reopening, because this is not resolved. The core problem is that the labels for /run/chrony and /run/chrony-dhcp are different: $ ls -lsadZ /run/chrony* 0 drwxr-x---. 2 chrony chrony system_u:object_r:chronyd_var_run_t:s0 80 Mar 4 13:20 /run/chrony/ 0 drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 60 Mar 4 10:40 /run/chrony-dhcp/ chronyd_t has wide permissions to chronyd_var_run_t: $ sesearch --allow --source chronyd_t --target chronyd_var_run_t allow chronyd_t chronyd_var_run_t:dir { add_name create ioctl link lock read remove_name rename reparent rmdir setattr unlink write }; allow chronyd_t chronyd_var_run_t:file { append create getattr ioctl link lock open read rename setattr unlink write }; allow chronyd_t chronyd_var_run_t:sock_file { create ioctl link lock read rename setattr unlink }; allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True allow domain file_type:file map; [ domain_can_mmap_files ]:True allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True allow domain pidfile:sock_file { append getattr open write }; allow nsswitch_domain pidfile:dir { getattr open search }; …but a much more restricted set of permissions to the generic var_run_t: $ sesearch --allow --source chronyd_t --target var_run_t allow chronyd_t var_run_t:dir { add_name remove_name write }; allow domain base_file_type:dir { getattr open search }; allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True allow domain file_type:file map; [ domain_can_mmap_files ]:True allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True allow domain pidfile:sock_file { append getattr open write }; allow domain var_run_t:dir { ioctl lock read }; allow domain var_run_t:lnk_file { getattr read }; allow nsswitch_domain pidfile:dir { getattr open search }; Because chronyd_t lacks the ability to read arbitrary var_run_t files, chronyd cannot load the *.sources files in /run/chrony-dhcp. The quickest solution would be to change /run/chrony-dhcp to have the chronyd_var_run_t label, the same as /run/chrony. But this would be wrong, because this would give chronyd_t the ability to write or remove files in /run/chrony-dhcp. And it should not have that ability: chronyd *consumes* files in /run/chrony-dhcp, but it does not produce them, and thus should not have the ability the write or remove files there. Giving chronyd_t read permission on any arbitrary var_run_t file would prevent the SELinux denial… but again, chronyd_t should not have that ability. It does not need to be able to read any arbitrary var_run_t file. I assert that the best solution here is to: 1. Create a new file context, e.g. chronyd_sources_var_run_t. 2. Give chronyd_t the ability to read files (and read/search directories) with the chronyd_sources_var_run_t context. 3. Change the file context of /run/chronyd-sources from var_run_t to chronyd_sources_var_run_t. These actions will give chronyd the ability to read the *.sources files in /run/chronyd-sources, but will not grant chronyd any wider permissions than that. Counterarguments?
OK, I see what's happening now. There are type transitions to ensure that when chronyd_t creates a dir/file/socket in a var_run_t directory, it transitions to chronyd_var_run_t: $ sesearch --type_trans --default chronyd_var_run_t type_transition chronyd_t var_run_t:dir chronyd_var_run_t; type_transition chronyd_t var_run_t:file chronyd_var_run_t; type_transition chronyd_t var_run_t:sock_file chronyd_var_run_t; type_transition initrc_t var_run_t:dir chronyd_var_run_t chrony-dhcp; On a fresh boot, the labels will be correct: $ ls -lsaZ /run/chrony* /run/chrony: total 4 0 drwxr-x---. 2 chrony chrony system_u:object_r:chronyd_var_run_t:s0 80 Mar 26 13:18 ./ 0 drwxr-xr-x. 59 root root system_u:object_r:var_run_t:s0 1660 Mar 26 13:20 ../ 4 -rw-r--r--. 1 root root system_u:object_r:chronyd_var_run_t:s0 5 Mar 26 13:17 chronyd.pid 0 srwxr-xr-x. 1 chrony chrony system_u:object_r:chronyd_var_run_t:s0 0 Mar 26 13:17 chronyd.sock= /run/chrony-dhcp: total 4 0 drwxr-xr-x. 2 root root system_u:object_r:chronyd_var_run_t:s0 60 Mar 26 13:18 ./ 0 drwxr-xr-x. 59 root root system_u:object_r:var_run_t:s0 1660 Mar 26 13:20 ../ 4 -rw-r--r--. 1 root root system_u:object_r:chronyd_var_run_t:s0 26 Mar 26 13:18 enp7s0.sources The problem is that SELinux file context policy isn't in alignment with the type transitions. So relabeling /run resets the file contexts to agree with the file policy, not the transition policy: $ restorecon -FR -v /run/chrony* Relabeled /run/chrony-dhcp from system_u:object_r:chronyd_var_run_t:s0 to system_u:object_r:var_run_t:s0 Relabeled /run/chrony-dhcp/enp7s0.sources from system_u:object_r:chronyd_var_run_t:s0 to system_u:object_r:var_run_t:s0 This breaks chronyd, because chronyd doesn't have permission to read var_run_t files. The solution is to bring the file context policy into alignment with the transition policies: $ semanage fcontext -a -f a -t chronyd_var_run_t -r 's0' '/var/run/chrony-dhcp(/.*)?' $ restorecon -FR -v /run/chrony* Relabeled /run/chrony-dhcp from system_u:object_r:var_run_t:s0 to system_u:object_r:chronyd_var_run_t:s0 Relabeled /run/chrony-dhcp/enp7s0.sources from system_u:object_r:var_run_t:s0 to system_u:object_r:chronyd_var_run_t:s0 It looks like this was already fixed upstream (at <https://github.com/fedora-selinux/selinux-policy>): commit 7ccbfc9ed1d2da09cb0c51b555fb2c9ffc68c515 Author: Zdenek Pytela <zpytela> Date: Thu Dec 10 17:48:03 2020 +0100 Add default file context for "/var/run/chrony-dhcp(/.*)?" With the 25d2a5c01c commit, a file transition for /var/run/chrony-dhcp was added, but it was not backed by the default file context specification. Resolves: rhbz#1895825 diff --git a/policy/modules/contrib/chronyd.fc b/policy/modules/contrib/chronyd.fc index 9c06350c2..668f40954 100644 --- a/policy/modules/contrib/chronyd.fc +++ b/policy/modules/contrib/chronyd.fc @@ -14,6 +14,7 @@ /var/log/chrony(/.*)? gen_context(system_u:object_r:chronyd_var_log_t,s0) /var/run/chrony(/.*)? gen_context(system_u:object_r:chronyd_var_run_t,s0) +/var/run/chrony-dhcp(/.*)? gen_context(system_u:object_r:chronyd_var_run_t,s0) /var/run/chronyd(/.*)? gen_context(system_u:object_r:chronyd_var_run_t,s0) /var/run/chrony-helper(/.*)? gen_context(system_u:object_r:chronyd_var_run_t,s0) /var/run/chronyd\.pid -- gen_context(system_u:object_r:chronyd_var_run_t,s0) …but this commit hasn't been backported to Fedora 33's selinux-policy yet.
Similar problem has been detected: Connected to a wifi network. hashmarkername: setroubleshoot kernel: 5.11.10-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-35.fc33.noarch reason: SELinux is preventing chronyd from 'read' accesses on the file wlp2s0.sources. type: libreport
I've submitted a Fedora PR to cherry-pick the commit: https://github.com/fedora-selinux/selinux-policy-contrib/pull/395 James, thank you for the analysis.
FEDORA-2021-050d4e8def has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-050d4e8def
FEDORA-2021-050d4e8def has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-050d4e8def` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-050d4e8def See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-050d4e8def has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.