Hide Forgot
Description of problem: When systemctl restart chrony-wait is run (and time is a bit off, I assume), AVC denial is logged. Version-Release number of selected component (if applicable): chrony-2.4-1.fc24.x86_64 How reproducible: Semi-deterministic. Steps to Reproduce: 1. Have Fedora 24 installed. 2. Set time five seconds back: date -s '-5 sec' 3. Run systemctl restart chrony-wait Actual results: type=AVC msg=audit(1467119106.048:204): avc: denied { sendto } for pid=671 comm="chronyd" path="/run/chrony/chronyc.1654.sock" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_dgram_socket permissive=0 Expected results: No AVC denial. Additional info:
The process of pid 1654 is /usr/bin/chronyc waitsync 600 0.1 0.0 1
The SELinux policy is selinux-policy-targeted-3.13.1-191.fc24.2.noarch.
I can actually see this on Fedora 23 as well: chrony-2.4-1.fc23.x86_64 selinux-policy-targeted-3.13.1-158.15.fc23.noarch I haven't seen it in automated Fedora 23 tests in the past and I see it with virtually every Fedora 24 setup now. But maybe Fedora 23 did not run chrony-wait in the past?
Is this something that https://bodhi.fedoraproject.org/updates/FEDORA-2016-7553eb6439 and https://bodhi.fedoraproject.org/updates/FEDORA-2016-4c9c2badcb could have caused?
chrony since 2.4 uses a Unix domain socket for communication between chronyd and chronyc (running with root privileges). There was a request to support this change in bug #1259636. I think it worked for me before, so I'm not sure if the initial support was incomplete or the policy has changed recently.
It's actually chrony version 2.2 and later which use the Unix socket. In Fedora 23 there was recently an update from 2.1.1 to 2.4
Do you think this is an issue in chrony, or should I move the bugzilla to selinux-policy?
I think it's a missing rule in the selinux policy. chronyd can't respond to chronyc when it's running as a service (it has unconfined_service_t context). As a quick workaround you can force chronyc in the chrony-wait service to not use Unix domain socket: sed 's|chronyc waitsync|chronyc -h ::1 waitsync|' \ < /usr/lib/systemd/system/chrony-wait.service \ > /etc/systemd/system/chrony-wait.service Another issue I noticed when I was trying different configuration directives is blocked access to /etc/adjtime: #============= chronyd_t ============== allow chronyd_t adjtime_t:file { read open getattr };
(In reply to Miroslav Lichvar from comment #10) > I think it's a missing rule in the selinux policy. chronyd can't respond to > chronyc when it's running as a service (it has unconfined_service_t context). > > As a quick workaround you can force chronyc in the chrony-wait service to > not use Unix domain socket: > > sed 's|chronyc waitsync|chronyc -h ::1 waitsync|' \ > < /usr/lib/systemd/system/chrony-wait.service \ > > /etc/systemd/system/chrony-wait.service I confirm that sed -i 's|chronyc waitsync|chronyc -h ::1 waitsync|' /usr/lib/systemd/system/chrony-wait.service makes the problem go away. Do we know what the proper fix (in the SELinux policy) would be? > Another issue I noticed when I was trying different configuration directives > is blocked access to /etc/adjtime: > > #============= chronyd_t ============== > allow chronyd_t adjtime_t:file { read open getattr };
Could we please get the proper fix in? The need to include workaround complicates our testing of other components.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Possibly a duplicate of bug 1284691?
*** Bug 1284691 has been marked as a duplicate of this bug. ***
The problem is with ExecStart=/usr/bin/chronyc waitsync 600 0.1 0.0 1 because /usr/bin/chronyc is labeled as bin_t and we end up with unconfined_service_t. We don't want to label it as chronyd_exec_t because of chronyc is a command line interface. Could we get a helper script here which we could label as chronyd_exec_t?
You mean to change the ExecStart line to call /usr/libexec/chrony-helper instead of /usr/bin/chronyc? We can do that, but this change wouldn't go upstream and I'd rather avoid adding another Fedora-specific patch. If this can't be fixed properly, I liked better the workaround from comment #10.
chrony-2.4-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1121fb57c9
chrony-2.4-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2ee0547cf1
chrony-2.4-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1390204 has been marked as a duplicate of this bug. ***
chrony-2.4-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1398980 has been marked as a duplicate of this bug. ***
chrony-2.4.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e62d5b25ee
(In reply to Fedora Update System from comment #28) > chrony-2.4.1-1.fc23 has been submitted as an update to Fedora 23. Long waits for the next flight in Toronto seem to have some advantages. :-) This refers to a duplicate bug 1398980.
chrony-2.4.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e62d5b25ee
chrony-2.4.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.