Bug 1470150 - SELinux is preventing chronyd from sendto access on the unix_dgram_socket
SELinux is preventing chronyd from sendto access on the unix_dgram_socket
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.4
Unspecified Unspecified
high Severity low
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
: Regression
: 1509927 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-12 09:01 EDT by RamaKasturi
Modified: 2017-11-10 14:54 EST (History)
19 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-175.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3153701 None None None 2017-08-16 08:56 EDT

  None (edit)
Description RamaKasturi 2017-07-12 09:01:17 EDT
Description of problem:
SELinux is preventing chronyd from sendto access on the unix_dgram_socket. Do not see any functionality impact.

#============= chronyd_t ==============

#!!!! The file '/run/chrony/chronyc.3781.sock' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /run/chrony/chronyc.3781.sock
allow chronyd_t unconfined_service_t:unix_dgram_socket sendto;

Following is seen in audit.log file:
=========================================
type=AVC msg=audit(1499843970.523:161): avc:  denied  { sendto } for  pid=1302 comm="chronyd" path="/run/chrony/chronyc.3936.sock" scontext=system_u:system_r:chronyd_t:s0 tc
ontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_dgram_socket

Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-165.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL7.4 RC candidate
2. Install HC 
3. Once installation is done run the command 'cat /var/log/audit/audit.log | audit2allow' to check if there are any denial.

Actual results:
Following is seen in audit.log and output from step 3 

#============= chronyd_t ==============

#!!!! The file '/run/chrony/chronyc.3781.sock' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /run/chrony/chronyc.3781.sock
allow chronyd_t unconfined_service_t:unix_dgram_socket sendto;

Following is seen in audit.log file:
=========================================
type=AVC msg=audit(1499843970.523:161): avc:  denied  { sendto } for  pid=1302 comm="chronyd" path="/run/chrony/chronyc.3936.sock" scontext=system_u:system_r:chronyd_t:s0 tc
ontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_dgram_socket



Expected results:
No AVCS should be seen.

Additional info:
Comment 2 RamaKasturi 2017-07-12 09:05:14 EDT
I have copied the audit log in the below location

http://rhsqe-repo.lab.eng.blr.redhat.com/sosreports/HC/1470150/
Comment 3 Zdenek Pytela 2017-08-16 08:21:35 EDT
A similar problem occurs when sosreport is run from cron:

----
type=PATH msg=audit(08/16/17 08:05:30.914:548) : item=0 name=/var/run/chrony/chronyc.4016.sock inode=85033 dev=00:13 mode=socket,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:chronyd_var_run_t:s0 objtype=NORMAL
type=CWD msg=audit(08/16/17 08:05:30.914:548) :  cwd=/
type=SOCKADDR msg=audit(08/16/17 08:05:30.914:548) : saddr={ fam=local path=/var/run/chrony/chronyc.4016.sock }
type=SYSCALL msg=audit(08/16/17 08:05:30.914:548) : arch=x86_64 syscall=sendto success=no exit=EACCES(Permission denied) a0=0x5 a1=0x7ffc0ed14c20 a2=0x1a8 a3=0x0 items=1 ppid=1 pid=11183 auid=unset uid=chrony gid=chrony euid=chrony suid=chrony fsuid=chrony egid=chrony sgid=chrony fsgid=chrony tty=(none) ses=unset comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=(null)
type=AVC msg=audit(08/16/17 08:05:30.914:548) : avc:  denied  { sendto } for  pid=11183 comm=chronyd path=/run/chrony/chronyc.4016.sock scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
----

In RHEL up to 7.3 it worked as expected, so adding the Regression keyword.

Reproduced with the package from RHEL 7.4:
selinux-policy-3.13.1-166.el7.noarch
Comment 5 Phil Randal 2017-09-01 07:06:18 EDT
I also get this problem when running the check_mk agent from xinetd:

----
type=AVC msg=audit(1504263710.254:218): avc:  denied  { sendto } for  pid=674 comm="chronyd" path="/run/chrony/chronyc.3970.sock" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:inetd_child_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1504263710.254:218): arch=c000003e syscall=44 success=yes exit=104 a0=5 a1=7ffc9d66ffb0 a2=68 a3=0 items=0 ppid=1 pid=674 auid=4294967295 uid=997 gid=995 euid=997 suid=997 fsuid=997 egid=995 sgid=995 fsgid=995 tty=(none) ses=4294967295 comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:chronyd_t:s0 key=(null)
type=PROCTITLE msg=audit(1504263710.254:218): proctitle="/usr/sbin/chronyd"
----

Worked in 7.3 as expected.
Comment 6 Troels Arvin 2017-09-02 15:50:37 EDT
I have also seen the problem when running the check_mk agent via systemd.

In /var/log/messages:
Sep  2 21:05:53 HOSTNAME dbus[628]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Sep  2 21:05:53 HOSTNAME dbus-daemon: dbus[628]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Sep  2 21:05:53 HOSTNAME dbus[628]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Sep  2 21:05:53 HOSTNAME dbus-daemon: dbus[628]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Sep  2 21:05:53 HOSTNAME setroubleshoot: SELinux is preventing /usr/sbin/chronyd from sendto access on the unix_dgram_socket /run/chrony/chronyc.29741.sock. For complete SELinux messages run: sealert -l 2df6c8ae-1f42-4203-9232-99c53bce8267
Sep  2 21:05:53 HOSTNAME python: SELinux is preventing /usr/sbin/chronyd from sendto access on the unix_dgram_socket /run/chrony/chronyc.29741.sock.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that chronyd should be allowed sendto access on the chronyc.29741.sock unix_dgram_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'chronyd' --raw | audit2allow -M my-chronyd#012# semodule -i my-chronyd.pp#012

In /var/log/audit/audit.log:
type=AVC msg=audit(1504380353.149:1249): avc:  denied  { sendto } for  pid=669 comm="chronyd" path="/run/chrony/chronyc.30369.sock" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_dgram_socket

If the two following lines are put in a temporary file /tmp/avcs.txt, then:
  audit2allow -M chronyd_rhel74_fix -i avcs.txt
will generate a .te file with the following content:
#============= chronyd_t ==============
module chronyd_rhel74_fix 1.0;

require {
        type chronyd_t;
        type unconfined_service_t;
        type inetd_child_t;
        class unix_dgram_socket sendto;
}

#============= chronyd_t ==============

#!!!! The file '/run/chrony/chronyc.29099.sock' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /run/chrony/chronyc.29099.sock
allow chronyd_t inetd_child_t:unix_dgram_socket sendto;

#!!!! The file '/run/chrony/chronyc.29619.sock' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /run/chrony/chronyc.29619.sock
allow chronyd_t unconfined_service_t:unix_dgram_socket sendto;
#======================================

Additionally, a file chronyd_rhel74_fix.pp will be produced. That file may be loaded like this:
semodule -i chronyd_rhel74_fix.pp

Now, the check_mk agent may correctly determine chronyd's state again.

Clearly a regression; I hope it will be fixed.
Comment 7 Milos Malik 2017-09-04 03:56:15 EDT
Which processes are running as unconfined_service_t, when the AVC appears?
Comment 8 Troels Arvin 2017-09-04 04:50:52 EDT
Here's the complete /var/log/audit/audit.log sequence, when the problem is triggered (by accessing port 6556 on a host which has the Check_MK agent running via a systemd socket):

===================================================
type=SERVICE_START msg=audit(1504514612.280:39184): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=check_mk@0-SOME_IP_ADDR:6556-192.168.42.59:49698 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1504514612.343:39185): avc:  denied  { sendto } for  pid=725 comm="chronyd" path="/run/chrony/chronyc.19144.sock" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1504514612.343:39185): arch=c000003e syscall=44 success=no exit=-13 a0=5 a1=7ffefc57cb70 a2=68 a3=0 items=0 ppid=1 pid=725 auid=4294967295 uid=422 gid=422 euid=422 suid=422 fsuid=422 egid=422 sgid=422 fsgid=422 tty=(none) ses=4294967295 comm="chronyd" exe="/usr/sbin/chronyd" subj=system_u:system_r:chronyd_t:s0 key=(null)
type=PROCTITLE msg=audit(1504514612.343:39185): proctitle="/usr/sbin/chronyd"
type=SERVICE_STOP msg=audit(1504514612.379:39186): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=check_mk@0-SOME_IP_ADDR:6556-192.168.42.59:49698 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AUTH msg=audit(1504514637.821:39187): pid=19299 uid=175 auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 msg='op=PAM:authentication grantors=pam_succeed_if acct="ovirtagent" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
type=USER_ACCT msg=audit(1504514637.821:39188): pid=19299 uid=175 auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 msg='op=PAM:accounting grantors=pam_permit acct="ovirtagent" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? res=success'
===================================================



Here's the content of the systemd unit file (check_mk.socket) which is involved above:
===================================================
# systemd socket definition file
[Unit]
Description=Check_MK Agent Socket

[Socket]
ListenStream=6556
Accept=true

[Install]
WantedBy=sockets.target
===================================================


and content of the related .service unit file (check_mk@.service):
===================================================
# systemd service definition file
[Unit]
Description=Check_MK

[Service]
ExecStart=/usr/bin/check_mk_agent

User=root
Group=root

StandardInput=socket
===================================================

"ls -lZ /usr/bin/check_mk_agent" gives:
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/check_mk_agent

I hope this is useful.
Comment 10 Robert Scheck 2017-10-05 15:03:21 EDT
Cross-filed ticket 01946759 on the Red Hat customer portal.
Comment 11 Lukas Vrabec 2017-10-19 09:25:07 EDT
Hi, 

From which rpm packages comes this binary? /usr/bin/check_mk_agent 
Thanks,
Lukas.
Comment 12 Andreas Luik 2017-10-19 09:40:10 EDT
check-mk-agent.x86_64 RPM from EPEL repo.

But the important point is to run chronyc from xinetd.
Comment 13 Miroslav Lichvar 2017-10-20 08:34:33 EDT
It seems this is due to the rebase of chrony to 3.1, which started using (by default) Unix domain sockets in /var/run/chrony for communication between chronyd and chronyc. chronyc can send a request and it's accepted by chronyd, but chronyd is blocked from sending the response.

check_mk and other monitoring tools don't need to use the socket if they use only commands that work also over the UDP socket (e.g. tracking, sources, sourcestats). chronyc can be started with -h 127.0.0.1,::1, or started under an unprivileged user, to avoid sending commands over the Unix domain socket.

However, other applications may use chronyc commands that work only over the Unix domain socket, so I think some fix of the policy will be needed in any case.
Comment 14 Lukas Vrabec 2017-10-20 08:40:09 EDT
Thanks Miroslav. 

I'll allow unconfined_service_t, system_cronjob_t and inetd_child_t to communicate with chronyd_t while we figure out something better.
Comment 19 Lukas Vrabec 2017-11-06 06:25:04 EST
*** Bug 1509927 has been marked as a duplicate of this bug. ***

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