Hide Forgot
Description of problem: type=AVC msg=audit(1387476806.505:39262): avc: denied { signull } for pid=25856 comm="smbd" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:cluster_t:s0 tclass=process type=SYSCALL msg=audit(1387476806.505:39262): arch=x86_64 syscall=kill success=no exit=EACCES a0=1f71 a1=0 a2=0 a3=0 items=0 ppid=18960 pid=25856 auid=4294967295 uid=0 gid=0 euid=712 suid=712 fsuid=712 Setup is this Samba handled by Pacemaker using this configuration: pcs resource create smb lsb:smb op monitor interval=60s pcs constraint colocation add smb drbdlinks INFINITY pcs constraint colocation add smb ip INFINITY pcs constraint order drbdlinks then smb pcs constraint order ip then smb Let the setup run for some undefined (?) time and this SELinux AVC denied shows up - at least we did nothing specific when this appeared. Version-Release number of selected component (if applicable): corosync-1.4.1-17.el6.x86_64 pacemaker-1.1.10-14.el6_5.1.x86_64 pcs-0.9.90-2.el6_5.2.noarch selinux-policy-targeted-3.7.19-231.el6.noarch samba-3.6.9-167.el6_5.x86_64 How reproducible: No idea. Just run that setup and wait? Actual results: AVC denied. Expected results: No AVC denied (either allow or dontaudit)
Currently the relations between smbd and cluster is that cluster transitions to smbd, I guess it sends a signull to its parent. Maybe we should add this to domtrans function. 005aad1390c4b15f8fb01a32720e1e08ec8d051d fixes this in git.
Cross-filed cases 01006700 and 01006701 (two different customers) in the Red Hat customer portal. Expected goal is that fix in a RHEL 6.5 SELinux update.
Interestingly we also saw this AVC denied meanwhile. Unfortunately I do not really understand if they are related nor was I able to figure out what that caused: type=AVC msg=audit(1388478998.941:111746): avc: denied { signull } for pid=10885 comm="smbd" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=process type=SYSCALL msg=audit(1388478998.941:111746): arch=x86_64 syscall=kill success=no exit=EACCES a0=5ce8 a1=0 a2=0 a3=0 items=0 ppid=18960 pid=10885 auid=4294967295 uid=0 gid=0 euid=720 suid=720 fsuid=720 egid=100 sgid=100 fsgid=100 tty=(none) ses=4294967295 comm=smbd exe=/usr/sbin/smbd subj=system_u:system_r:smbd_t:s0 key=(null)
Could smbd be sending signull to all processes on the system?
Could maybe one of the samba guys explain that behaviour?
type=AVC msg=audit(1390474941.333:62168): avc: denied { signull } for pid=1374 comm="smbd" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:ksmtuned_t:s0 tclass=process type=SYSCALL msg=audit(1390474941.333:62168): arch=x86_64 syscall=kill success=no exit=EACCES a0=5332 a1=0 a2=0 a3=0 items=0 ppid=14867 pid=1374 auid=4294967295 uid=0 gid=0 euid=676 suid=676 fsuid=676 egid=100 sgid=100 fsgid=100 tty=(none) ses=4294967295 comm=smbd exe=/usr/sbin/smbd subj=system_u:system_r:smbd_t:s0 key=(null)
Andreas, might you please enlight us why Samba is sending SIGNULL to random processes? type=AVC msg=audit(1391192935.403:53654): avc: denied { signull } for pid=12369 comm="smbd" scontext=unconfined_u:system_r:smbd_t:s0 tcontext=unconfined_u:system_r:drbd_t:s0 tclass=process type=SYSCALL msg=audit(1391192935.403:53654): arch=x86_64 syscall=kill success=no exit=EACCES a0=678f a1=0 a2=0 a3=0 items=0 ppid=11343 pid=12369 auid=0 uid=0 gid=0 euid=695 suid=695 fsuid=695 egid=100 sgid=100 fsgid=100 tty=(none) ses=7298 comm=smbd exe=/usr/sbin/smbd subj=unconfined_u:system_r:smbd_t:s0 key=(null)
We have a function process_exists_by_pid() which uses kill(pid, 0) to check if a child still exists ...
(In reply to Robert Scheck from comment #8) > Andreas, might you please enlight us why Samba is sending SIGNULL to random > processes? > > type=AVC msg=audit(1391192935.403:53654): avc: denied { signull } for > pid=12369 comm="smbd" scontext=unconfined_u:system_r:smbd_t:s0 > tcontext=unconfined_u:system_r:drbd_t:s0 tclass=process > type=SYSCALL msg=audit(1391192935.403:53654): arch=x86_64 syscall=kill > success=no exit=EACCES a0=678f a1=0 a2=0 a3=0 items=0 ppid=11343 pid=12369 > auid=0 uid=0 gid=0 euid=695 suid=695 fsuid=695 egid=100 sgid=100 fsgid=100 > tty=(none) ses=7298 comm=smbd exe=/usr/sbin/smbd > subj=unconfined_u:system_r:smbd_t:s0 key=(null) Samba is using kill(pid, 0) to check process existence but only does so for own processes or processes started by smbd (like for printing spoolers or async DNS resolver child).
(In reply to Alexander Bokovoy from comment #11) > Samba is using kill(pid, 0) to check process existence but only does so for > own processes or processes started by smbd (like for printing spoolers or > async DNS resolver child). From my point of view your explanation differs between the actual behaviour that is catched by SELinux. Or am I mistaken? I would say, that smbd sends its kill(pid, 0) to random processes. I can not see how a Postfix or KVM or DRBD could be own processes or processes started by smbd. In the end, all of these processes are started by Pacemaker - that is the only common thing, that I can see. Further ideas? Is this a leaking file descriptor thing leading to false stuff?
Well, if the child process died or already exited and we call kill(pid, 0) and this pid was already assigned to a new process, then we will send the signal to another process.
That means Samba works as expected and SELinux policy should instead simply have an additional dontaudit for any process to not wake up setroubleshootd?
c97b28f27ade644a0a34abfa64079f88f3bfe1ec fixes this in git.
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. http://rhn.redhat.com/errata/RHBA-2014-1568.html