Description of problem: Something has changed between selinux-policy 34.13 and 34.14 which breaks the upstream chrony test suite when working with the system chronyd binary. This broke before, but I found a workaround setting context of the tests to system_u:object_r:chronyd_var_run_t:s0. That seems to no longer work. If there is a proper way how tests should do this, please let me know. Version-Release number of selected component (if applicable): selinux-policy-34.15-1.fc35.noarch How reproducible: always Steps to Reproduce: 1. cd /tmp 2. git clone --depth 1 https://github.com/mlichvar/chrony.git 3. chcon -R system_u:object_r:chronyd_var_run_t:s0 chrony 4. cd chrony/test/system 5. ./002-extended Actual results: FAIL Expected results: PASS Additional info: type=AVC msg=audit(1628516160.085:685): avc: denied { sendto } for pid=72428 comm="chronyc" path="/tmp/chrony/test/system/tmp/chronyd.sock" scontext=unconfined_u:unconfined_r:chronyc_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0
Seems to be a side effect of this commit: commit 4b4eec49a5540459b0e89eb2c4a776ee5e9a66ac Author: Patrik Koncity <pkoncity> Date: Fri Oct 23 19:44:45 2020 +0200 Removed adding to attribute unpriv_userdomain from userdom_unpriv_type template new# sesearch -A -s chronyc_t -t unconfined_t -c unix_dgram_socket -p sendto old# sesearch -A -s chronyc_t -t unconfined_t -c unix_dgram_socket -p sendto allow chronyc_t unpriv_userdomain:unix_dgram_socket sendto; > This broke before, but I found a workaround setting context of the tests to system_u:object_r:chronyd_var_run_t:s0. That seems to no longer work. I may not understand well the tests, but I think changing the type of /tmp/chrony/test/system/tmp/chronyd.sock or possibly all in /tmp/chrony/test/system/tmp should be sufficient and considered a part of the test setup, not a workaround.
Ok, I don't understand this well enough to be sure what is expected and what is not. Changing the context of the socket directly is not possible as it is created by chronyd when started. Starting the test with runcon doesn't seem to work as it doesn't have the permissions to execute the script. Do I need to patch the scripts to start chronyd with runcon?
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/844 I added the permission for ptp4l as well. It would be helpful if you could review the commit message and test with the selinux-policy package: Show all checks -> build-rpm -> Details -> Artifacts -> rpms in SELinux enforcing mode. (In reply to Miroslav Lichvar from comment #2) > Ok, I don't understand this well enough to be sure what is expected and what > is not. Changing the context of the socket directly is not possible as it is > created by chronyd when started. Starting the test with runcon doesn't seem > to work as it doesn't have the permissions to execute the script. Do I need > to patch the scripts to start chronyd with runcon? I am sorry for not being precise enough. What I meant was: 1. The missing permission needs to be addressed in selinux-policy. 2. To test the feature, the test itself should include some selinux setup to mimic real scenario, too, for instance using /tmp/chrony/test/system/run and setting file context equivalency: # mkdir -p /tmp/chrony/test/system/run # semanage fcontext -a -e /var/run /tmp/chrony/test/system/run # restorecon -Rv /tmp/chrony/test/system/run as transitions work with types: # sesearch -T -s chronyd_t -t var_run_t -c sock_file type_transition chronyd_t var_run_t:sock_file chronyd_var_run_t;
chronyc and pmc don't talk to each other. They are two different issues (which I thought had the same cause). pmc talks to ptp4l and chronyc talks to chronyd. The commit messages needs to be updated. I tried the reproducer from comment #0 with the new rpms and it still failed. Do I need to make the changes you suggested with the run directory to make it work as expected?
(In reply to Miroslav Lichvar from comment #5) > chronyc and pmc don't talk to each other. They are two different issues > (which I thought had the same cause). pmc talks to ptp4l and chronyc talks > to chronyd. The commit messages needs to be updated. The avc denial reads: type=AVC msg=audit(1628516160.085:685): avc: denied { sendto } for pid=72428 comm="chronyc" path="/tmp/chrony/test/system/tmp/chronyd.sock" scontext=unconfined_u:unconfined_r:chronyc_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0 We can clearly identify chronyc as one party, about the other one we can only say it is not the chronyd service - can you show the context for chronyd? # ps -eo pid,ppid,command,context | grep -e CONTEXT -e unconfined_t -e chronyd PID PPID COMMAND CONTEXT 822 1 /usr/sbin/chronyd system_u:system_r:chronyd_t:s0 ... > > I tried the reproducer from comment #0 with the new rpms and it still > failed. Do I need to make the changes you suggested with the run directory > to make it work as expected? You can keep the test as long as it behaves expectedly. The denial is the same as in #c0 or in the RHEL bug?
The denial is the same as in #c0. chronyd is started and stopped by the test. It's not the system chronyd service. If I patch the test to sleep a bit before killing the process, I see it runs as unconfined.
FEDORA-2021-ad4033a9b0 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ad4033a9b0
FEDORA-2021-ad4033a9b0 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-ad4033a9b0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ad4033a9b0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-ad4033a9b0 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.