Auditd misses accept syscalls from sshd

[Paul Moore]

On Fri, Dec 2, 2016 at 4:42 PM, Nathan Cooprider
<ncooprider at yankeehacker.com> wrote:
> On Fri, Dec 2, 2016 at 4:26 PM Paul Moore <paul at paul-moore.com> wrote:
>>
>> On Fri, Dec 2, 2016 at 3:43 PM, Nathan Cooprider
>> <ncooprider at yankeehacker.com> wrote:
>> > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. I tried
>> > versions
>> > 2.3.2 and 2.4.5 of the daemon with kernel versions 3.13.0-96 and
>> > 4.4.0-47.
>> > In all cases the accept syscall (43) failed to show up until after I
>> > restarted the ssh daemon. It's especially weird because I don't see this
>> > problem on Ubuntu 16 (4.4.0-38). Any thoughts about why I am seeing this
>> > or
>> > where to look?
>> >
>> > I found a similar question in the archives, but it seems to do with the
>> > architecture size and not OS versions:
>> > https://www.redhat.com/archives/linux-audit/2015-January/msg00060.html
>> >
>> > I also posted this question on Stack Overflow:
>> >
>> > http://stackoverflow.com/questions/40940225/why-does-sshd-accept-syscall-have-inconsistent-behavior-in-linux-audit-framework
>>
>> I'm not really very aware of what Ubuntu is doing wrt to their default
>> audit configuration, but this really sounds like you need to add
>> 'audit=1' to the kernel command line.
>
> 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.

If you haven't already, I would suggest opening an issue with
Ubuntu/Canonical; I'm not aware of any issues in current kernels that
would cause this and your testing on more modern Ubuntu flavors would
indicate current Ubuntu releases work correctly.

-- 
paul moore
www.paul-moore.com