Bug 974305 - SELinux is preventing /usr/sbin/chronyd from using the 'getsession' accesses on a process.
SELinux is preventing /usr/sbin/chronyd from using the 'getsession' accesses ...
Product: Fedora
Classification: Fedora
Component: chrony (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-13 18:41 EDT by Adam Williamson
Modified: 2013-11-19 10:01 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-19 10:01:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-06-13 18:41:00 EDT
Description of problem:
Just popped up on a reboot (system had hung prior to the reboot).
SELinux is preventing /usr/sbin/chronyd from using the 'getsession' accesses on a process.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that chronyd should be allowed getsession access on processes labeled audisp_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep chronyd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:chronyd_t:s0
Target Context                system_u:system_r:audisp_t:s0
Target Objects                 [ process ]
Source                        chronyd
Source Path                   /usr/sbin/chronyd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           chrony-1.27-3.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-48.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.9.5-301.fc19.x86_64 #1 SMP Tue
                              Jun 11 19:39:38 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-06-13 15:38:13 PDT
Last Seen                     2013-06-13 15:38:13 PDT
Local ID                      a80fc3bb-2a6e-4870-823f-c928664eb656

Raw Audit Messages
type=AVC msg=audit(1371163093.923:25): avc:  denied  { getsession } for  pid=597 comm="chronyd" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:audisp_t:s0 tclass=process

type=SYSCALL msg=audit(1371163093.923:25): arch=x86_64 syscall=getsid success=no exit=EACCES a0=23c a1=1 a2=7fd12a5cb7d8 a3=23c items=0 ppid=1 pid=597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=(null)

Hash: chronyd,chronyd_t,audisp_t,process,getsession

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.5-301.fc19.x86_64
type:           libreport
Comment 1 Daniel Walsh 2013-06-15 07:21:55 EDT
Does chrony have anything to do with audit?
Comment 2 Miroslav Lichvar 2013-06-17 04:30:30 EDT
Chrony doesn't have anything to do with audit.

On start, when /var/run/chronyd.pid exists, chronyd tries getsid(pid) to see if there is another chronyd running. How could this happen on boot, when /var/run is empty, I'm not sure.
Comment 3 Miroslav Lichvar 2013-11-19 10:01:39 EST
It seems recent systemd versions remove pid file specified in the service file when the service is stopped. chronyd is normally unable to remove its pid file when stopping due to dropped root permissions, but we can now let systemd to do it and prevent the problem with another process reusing the same pid and chronyd trying to run getsid() on it.

This is in chrony-1.29-3.fc21.

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