<div dir="ltr">To clarify, I don't think sshd is causing an issue, I think the audit system is in some broken state (broken from my perspective, this could be working as intended) where processes attempting to send audit messages are hanging. The backtrace is meant to show an example of a process hung trying to send an audit message. This happened almost immediately after starting osquery on the instance, where osquery attempted to acquire the audit handle when it was already being held by another process: Lacework. Hopefully this makes more sense. I ran into this issue on a subset (~20) of my instances while attempting to deploy osquery to a few hundred instances in my fleet. It looks like it's only affecting a range of kernels. I'm going to try and put together a reproduction case.<div><br></div><div>Unaffected</div><div>4.4.41-36.55.amzn1.x86_64</div><div><br></div><div>Affected</div><div>4.9.51-10.52.amzn1.x86_64</div><div><span style="color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px;background-color:rgb(244,245,247);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">4.9.77-31.58.amzn1.x86_64</span><br><div><br></div><div><div><br></div><div>Preston</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 18, 2018 at 11:50 AM, Richard Guy Briggs <span dir="ltr"><<a href="mailto:rgb@redhat.com" target="_blank">rgb@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2018-06-14 23:12, Preston Bennes wrote:<br>
> Greetings audit mailing list,<br>
> <br>
> I've got an AWS instance running an Amazon Linux kernel,<br>
> 4.9.77-31.58.amzn1.x86_64<br>
> with the base OS being CentOS 6. The instance had one program with the<br>
> audit handle (Proprietary closed source software, Lacework agent). I<br>
> installed and started OSQuery which attempted to acquire the audit handle.<br>
> I'm unsure if osquery was successful or not, because I was unable to ssh in<br>
> to the server to investigate. I ended up having to restart the instance.<br>
> Almost immediately after starting osquery, sshd got stuck in D state.<br>
> syslog has a hung task warning and backtrace that provides some information:<br>
<br>
</span>[reformatting dump info to be more readable...]<br>
<span class="">> INFO: task sshd:1840 blocked for more than 10 seconds.<br>
</span><span class="">> Tainted: G            E   4.9.77-31.58.amzn1.x86_64 #1<br>
</span><span class="">> "echo 0 > /proc/sys/kernel/hung_task_<wbr>timeout_secs" disables this message.<br>
</span><span class="">> sshd            D    0  1840   1839 0x00000080<br>
</span>> 0000000000000000 ffff8802025c6540 ffff88003684d940 ffff880205f3bb80<br>
> ffff8802072582c0 ffffc900049bfc60 ffffffff81556e62 0000000000000001<br>
> 004200ca00000001 ffff8802072582c0 0000000000000000 ffffffff81a65140<br>
> Call Trace:<br>
> [<ffffffff81556e62>] ? __schedule+0x242/0x700<br>
> [<ffffffff8155734c>] schedule+0x2c/0x80<br>
> [<ffffffff815575ee>] schedule_preempt_disabled+0xe/<wbr>0x10<br>
> [<ffffffff81558f05>] __mutex_lock_slowpath+0x95/<wbr>0x110<br>
> [<ffffffff8147a6f8>] ? __alloc_skb+0x78/0x1e0<br>
> [<ffffffff81558f97>] mutex_lock+0x17/0x30<br>
> [<ffffffff811178bd>] audit_receive+0x1d/0x90<br>
> [<ffffffff814c4976>] netlink_unicast+0x176/0x220<br>
> [<ffffffff814c4cf6>] netlink_sendmsg+0x2d6/0x390<br>
> [<ffffffff814719fe>] sock_sendmsg+0x3e/0x50<br>
> [<ffffffff81471ead>] SYSC_sendto+0x11d/0x150<br>
> [<ffffffff8111c68b>] ? __audit_syscall_entry+0xbb/<wbr>0x100<br>
> [<ffffffff81003478>] ? syscall_trace_enter+0x1c8/<wbr>0x2c0<br>
> [<ffffffff814728ee>] SyS_sendto+0xe/0x10<br>
> [<ffffffff81003b09>] do_syscall_64+0x59/0xc0<br>
<span class="">> [<ffffffff8155bd70>] entry_SYSCALL64_slow_path+<wbr>0x25/0x25<br>
> <br>
> I've been doing some reading (ex.<br>
> <a href="https://www.redhat.com/archives/linux-audit/2016-February/msg00025.html" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>archives/linux-audit/2016-<wbr>February/msg00025.html</a> )<br>
> and my understanding is that osquery should have been able to acquire the<br>
> audit handle, trampling lacework's ("Last one wins"), but I don't have<br>
<br>
</span>"Last one wins" has been fixed for a couple of years now.  That<br>
behaviour orphaned a previous daemon which was a bug.  For your usage,<br>
there still can "only be one".  There is work to enable multiple audit<br>
daemons, but not for this sort of reason.<br>
<span class=""><br>
> access to the Lacework code to know how it might handle that situation (I'm<br>
> engaging their support separately). I also noticed the patch set for 4.17<br>
> seemed to include some changes around the code path in the backtrace. I'm<br>
> trying to understand this behavior and determine if it's a bug, if said bug<br>
> has already been fixed by a patch between 4.9.77 and 4.17, or that this<br>
> issue is a lack of my understanding of the behavior of the audit system. It<br>
> is surprising to me that an audit system related issue would result in sshd<br>
> getting stuck in D state. Several other processes on the system continued<br>
> running without incident. Processed launched out of cron also got stuck in<br>
> D state. I would be grateful for some expert insight. If this isn't a bug<br>
> and is a misunderstanding on my part, is there any way to configure the<br>
> audit system such that an issue won't result in processes getting stuck in<br>
> D state?<br>
<br>
</span>I don't quite understand how sshd is implicated other than it sending<br>
USER class messages to audit for logging.  This shouldn't conflict with<br>
any daemon contention issues.<br>
<br>
> Thanks,<br>
> Preston Bennes<br>
<br>
- RGB<br>
<br>
--<br>
Richard Guy Briggs <<a href="mailto:rgb@redhat.com">rgb@redhat.com</a>><br>
Sr. S/W Engineer, Kernel Security, Base Operating Systems<br>
Remote, Ottawa, Red Hat Canada<br>
IRC: rgb, SunRaycer<br>
Voice: +1.647.777.2635, Internal: (81) 32635<br>
</blockquote></div><br></div>