Auditd misses accept syscalls from sshd

[Steve Grubb]

On Friday, December 2, 2016 3:44:35 PM EST Hassan Sultan wrote:
> On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider
> 
> <ncooprider at yankeehacker.com> wrote:
> > Thanks for the suggestion. I'm getting other audit events from sshd
> > without restarting ssh. It's just the accept syscalls that do not show
> > up until after I >restart ssh:
> > 
> > type=SYSCALL msg=audit(1480714641.465:54): arch=c000003e syscall=43
> > success=yes exit=5 a0=3 a1=7ffce3b031b0 a2=7ffce3b0319c a3=0 items=0
> > 
> > >ppid=1 pid=2602 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > 
> > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
> > exe="/usr/sbin/>sshd" key=(null)
> > 
> > I think that indicates the kernel is sending up audit messages. My
> > question is why the above message fails to come up until after I've
> > restarted ssh.
> 
> (I was the person having that issue almost 2 years ago)
> 
> I never fully investigated it, but came up with one theory explaining it :
> 
> - accept is a blocking syscall , it might be that sshd started and the
> syscall was initiated before the audit rule was loaded. This would explain
> why you see the event when restarting sshd.

Because accept can block, sockets are almost always turned non-blocking when 
setting up the listen queue. Then you wait in select/poll/epoll for it to be 
ready to accept. And inspection of sshd's code and some stracing shows this to 
be the case.
 
> Don't use the tcp connection time to evaluate whether the auditing worked
> properly, but rather when the initial accept call was made, which
> basically amounts to when sshd is started.

On most systems, auditd starts just before or after syslog. Networking daemons 
usually come later in the boot process.

-Steve