Re: Auditd misses accept syscalls from sshd
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(a)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