Bug 1470150

I have copied the audit log in the below location

http://rhsqe-repo.lab.eng.blr.redhat.com/sosreports/HC/1470150/

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

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.

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.

Which processes are running as unconfined_service_t, when the AVC appears?

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.

Cross-filed ticket 01946759 on the Red Hat customer portal.

Hi, 

From which rpm packages comes this binary? /usr/bin/check_mk_agent 
Thanks,
Lukas.

check-mk-agent.x86_64 RPM from EPEL repo.

But the important point is to run chronyc from xinetd.

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.

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.

*** Bug 1509927 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0763