From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 20:43:46 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3297110906082804196==" Return-path: Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2Ki00j031352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 15:44:00 -0500 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F8567DD06 for ; Fri, 2 Dec 2016 20:43:59 +0000 (UTC) Received: by mail-vk0-f48.google.com with SMTP id x186so152171436vkd.1 for ; Fri, 02 Dec 2016 12:43:59 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============3297110906082804196== Content-Type: multipart/alternative; boundary=001a113dc5884680180542b2ffe7 --001a113dc5884680180542b2ffe7 Content-Type: text/plain; charset=UTF-8 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 --001a113dc5884680180542b2ffe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Auditd seems to miss accept syscalls from ssh on Ubun= tu 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 becau= se 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-aud= it/2015-January/msg00060.html


--001a113dc5884680180542b2ffe7-- --===============3297110906082804196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3297110906082804196==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 16:09:44 -0500 Message-ID: <3811129.XXtPaolnaT@x2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. Its not auditd, the kernel does all the work. Auditd acts a lot like a specialized syslog. :-) > 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? It works fine on my 4.8 kernel: # uname -r 4.8.10-200.fc24.x86_64 # auditctl -a always,exit -F arch=b64 -S accept,accept4 -F exe=/usr/sbin/sshd -F key=test # ssh localhost # exit # ausearch --start recent -k test -i ---- type=CONFIG_CHANGE msg=audit(12/02/2016 15:53:00.297:917) : auid=sgrubb ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" key=test list=exit res=yes ---- type=PROCTITLE msg=audit(12/02/2016 15:53:07.287:919) : proctitle=/usr/sbin/sshd type=SOCKADDR msg=audit(12/02/2016 15:53:07.287:919) : saddr={ fam=inet6 laddr=::1 lport=52740 } type=SYSCALL msg=audit(12/02/2016 15:53:07.287:919) : arch=x86_64 syscall=accept success=yes exit=5 a0=0x4 a1=0x7ffdd5bd06a0 a2=0x7ffdd5bd068c a3=0x0 items=0 ppid=1 pid=1071 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=test I don't know if there were any bug fixes that made it start working. I also think I was doing some testing on kernels close to when the audit by executable code first went upstream and I remember not getting the results I wanted. I had other things to do and when I came back to it I could not replicate the missing events. I had upgraded the kernel in the mean time. Does using a newer kernel fix it for you? -Steve > 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-hav > e-inconsistent-behavior-in-linux-audit-framework From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 2 Dec 2016 16:26:29 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx09.extmail.prod.ext.phx2.redhat.com [10.5.110.38]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2LQVru012373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 16:26:31 -0500 Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75EF6CA611 for ; Fri, 2 Dec 2016 21:26:30 +0000 (UTC) Received: by mail-ua0-f170.google.com with SMTP id 51so294400053uai.1 for ; Fri, 02 Dec 2016 13:26:30 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, Dec 2, 2016 at 3:43 PM, Nathan Cooprider 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. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 21:42:02 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4496790220968826915==" Return-path: Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2LgHkL007338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 16:42:17 -0500 Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B8B48B977 for ; Fri, 2 Dec 2016 21:42:15 +0000 (UTC) Received: by mail-ua0-f172.google.com with SMTP id b35so294339694uaa.3 for ; Fri, 02 Dec 2016 13:42:15 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============4496790220968826915== Content-Type: multipart/alternative; boundary=94eb2c04cabcb3db100542b3cf79 --94eb2c04cabcb3db100542b3cf79 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 4:26 PM Paul Moore wrote: > On Fri, Dec 2, 2016 at 3:43 PM, Nathan Cooprider > 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. > > -- > paul moore > www.paul-moore.com 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. --94eb2c04cabcb3db100542b3cf79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2,= 2016 at 4:26 PM Paul Moore <paul= @paul-moore.com> wrote:
On F= ri, Dec 2, 2016 at 3:43 PM, Nathan Cooprider
<ncooprider@yankeehacker.com> wrote:
> Auditd seems to miss accept syscalls from ssh on Ubuntu 14. I tried ve= rsions
> 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 th= is or
> where to look?
>
> I found a similar question in the archives, but it seems to do with th= e
> 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/q= uestions/40940225/why-does-sshd-accept-syscall-have-inconsistent-behavior-i= n-linux-audit-framework

I'm not really very aware of what Ubuntu is doing wrt to their default<= br class=3D"gmail_msg"> audit configuration, but this really sounds like you need to add
'audit=3D1' to the kernel command line.

--
paul moore
www.paul-moore.com

= Thanks for the suggestion. I'm getting other audit events from sshd wit= hout restarting ssh. It's just the accept syscalls that do not show up = until after I restart ssh:

type=3DSYSCALL msg= =3Daudit(1480714641.465:54): arch=3Dc000003e syscall=3D43 success=3Dyes exi= t=3D5 a0=3D3 a1=3D7ffce3b031b0 a2=3D7ffce3b0319c a3=3D0 items=3D0 ppid=3D1 = pid=3D2602 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 eg= id=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D"sshd&q= uot; exe=3D"/usr/sbin/sshd" key=3D(null)

=
I think that indicates the kernel is sending up audit messages. My que= stion is why the above message fails to come up until after I've restar= ted ssh.

--94eb2c04cabcb3db100542b3cf79-- --===============4496790220968826915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4496790220968826915==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 21:55:17 +0000 Message-ID: References: <3811129.XXtPaolnaT@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1222673624774839771==" Return-path: In-Reply-To: <3811129.XXtPaolnaT@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb , linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1222673624774839771== Content-Type: multipart/alternative; boundary=94eb2c04cabc0bdcca0542b3ff05 --94eb2c04cabc0bdcca0542b3ff05 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb wrote: > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. > > Its not auditd, the kernel does all the work. Auditd acts a lot like a > specialized syslog. :-) > > > > 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? > > It works fine on my 4.8 kernel: > # uname -r > 4.8.10-200.fc24.x86_64 > > # auditctl -a always,exit -F arch=b64 -S accept,accept4 -F > exe=/usr/sbin/sshd -F key=test > > # ssh localhost > # exit > > # ausearch --start recent -k test -i > ---- > type=CONFIG_CHANGE msg=audit(12/02/2016 15:53:00.297:917) : auid=sgrubb > ses=5 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" > key=test > list=exit res=yes > ---- > type=PROCTITLE msg=audit(12/02/2016 15:53:07.287:919) : > proctitle=/usr/sbin/sshd > type=SOCKADDR msg=audit(12/02/2016 15:53:07.287:919) : saddr={ fam=inet6 > laddr=::1 lport=52740 } > type=SYSCALL msg=audit(12/02/2016 15:53:07.287:919) : arch=x86_64 > syscall=accept success=yes exit=5 a0=0x4 a1=0x7ffdd5bd06a0 > a2=0x7ffdd5bd068c > a3=0x0 items=0 ppid=1 pid=1071 auid=unset uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset > comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > key=test > > I don't know if there were any bug fixes that made it start working. I also > think I was doing some testing on kernels close to when the audit by > executable code first went upstream and I remember not getting the results > I > wanted. I had other things to do and when I came back to it I could not > replicate the missing events. I had upgraded the kernel in the mean time. > > Does using a newer kernel fix it for you? > > -Steve > > > 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-hav > > e-inconsistent-behavior-in-linux-audit-framework > I just tried again and had the same problem: vagrant@vagrant:~$ uname -a Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux That's a newer version than I have on my Ubuntu 16 VM, which does demonstrate the problem. It's also strange that restarting ssh then makes the accept syscall events show up. Other sshd syscalls show up in auditd before and after the ssh restart. --94eb2c04cabc0bdcca0542b3ff05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2,= 2016 at 4:09 PM Steve Grubb <sgrub= b@redhat.com> wrote:
On Frid= ay, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote:
> Auditd seems to miss accept syscalls from ssh on Ubuntu 14.

Its not auditd, the kernel does all the work. Auditd acts a lot like a
specialized syslog.=C2=A0 :-)


> 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 b= ecause 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?

It works fine on my 4.8 kernel:
# uname -r
4.8.10-200.fc24.x86_64

# auditctl -a always,exit -F arch=3Db64 -S accept,accept4 -F exe=3D/usr/sbi= n/sshd -F key=3Dtest

# ssh localhost
# exit

# ausearch --start recent -k test -i
----
type=3DCONFIG_CHANGE msg=3Daudit(12/02/2016 15:53:00.297:917) : auid=3Dsgru= bb ses=3D5
subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=3D"add= _rule" key=3Dtest
list=3Dexit res=3Dyes
----
type=3DPROCTITLE msg=3Daudit(12/02/2016 15:53:07.287:919) : proctitle=3D/us= r/sbin/sshd
type=3DSOCKADDR msg=3Daudit(12/02/2016 15:53:07.287:919) : saddr=3D{ fam=3D= inet6 laddr=3D::1 lport=3D52740 }
type=3DSYSCALL msg=3Daudit(12/02/2016 15:53:07.287:919) : arch=3Dx86_64
syscall=3Daccept success=3Dyes exit=3D5 a0=3D0x4 a1=3D0x7ffdd5bd06a0 a2=3D0= x7ffdd5bd068c
a3=3D0x0 items=3D0 ppid=3D1 pid=3D1071 auid=3Dunset uid=3Droot gid=3Droot e= uid=3Droot
suid=3Droot fsuid=3Droot egid=3Droot sgid=3Droot fsgid=3Droot tty=3D(none) = ses=3Dunset
comm=3Dsshd exe=3D/usr/sbin/sshd subj=3Dsystem_u:system_r:sshd_t:s0-s0:c0.c= 1023
key=3Dtest

I don't know if there were any bug fixes that made it start working. I = also
think I was doing some testing on kernels close to when the audit by
executable code first went upstream and I remember not getting the results = I
wanted. I had other things to do and when I came back to it I could not
replicate the missing events. I had upgraded the kernel in the mean time.
Does using a newer kernel fix it for you?

-Steve

> I found a similar question in the archives, but it seems to do with th= e
> 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-h= av
> e-inconsistent-behavior-in-linux-audit-framework

=C2=A0I just tried again and had the sam= e problem:

vagrant@vagrant:~$ uname -a
Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:3= 0 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

That'= ;s a newer version than I have on my Ubuntu 16 VM, which does demonstrate t= he problem. It's also strange that restarting ssh then makes the accept= syscall events show up. Other sshd syscalls show up in auditd before and a= fter the ssh restart.
--94eb2c04cabc0bdcca0542b3ff05-- --===============1222673624774839771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1222673624774839771==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 2 Dec 2016 16:56:49 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2Luq00009772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 16:56:52 -0500 Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C89499D76C for ; Fri, 2 Dec 2016 21:56:50 +0000 (UTC) Received: by mail-ua0-f181.google.com with SMTP id 12so295288289uas.2 for ; Fri, 02 Dec 2016 13:56:50 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, Dec 2, 2016 at 4:42 PM, Nathan Cooprider wrote: > On Fri, Dec 2, 2016 at 4:26 PM Paul Moore wrote: >> >> On Fri, Dec 2, 2016 at 3:43 PM, Nathan Cooprider >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 17:13:42 -0500 Message-ID: <3309840.oCxPxWEFuR@x2> References: <3811129.XXtPaolnaT@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, Addressing a couple obvious things here... On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote: > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb wrote: > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. > > > > Its not auditd, the kernel does all the work. Auditd acts a lot like a > > specialized syslog. :-) > > > > > I tried versions 2.3.2 and 2.4.5 of the daemon Support was not added until 2.5. > > > with kernel versions 3.13.0-96 Definitely won't support it. > > > and 4.4.0-47. The feature landed in 4.3, so 4.4 should have it. However, you need audit 2.5 or later to use the kernel feature. > I just tried again and had the same problem: > > vagrant@vagrant:~$ uname -a > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Try pairing that with a newer auditd so that auditctl has the support to load the rule. -Steve > That's a newer version than I have on my Ubuntu 16 VM, which does > demonstrate the problem. It's also strange that restarting ssh then makes > the accept syscall events show up. Other sshd syscalls show up in auditd > before and after the ssh restart. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hassan Sultan" Subject: Re: Auditd misses accept syscalls from sshd Date: Fri, 02 Dec 2016 15:44:35 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1747884116339411592==" Return-path: Received: from mx1.redhat.com (ext-mx07.extmail.prod.ext.phx2.redhat.com [10.5.110.31]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2Niatr020090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 18:44:36 -0500 Received: from homiemail-a69.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9973AC04FF82 for ; Fri, 2 Dec 2016 23:44:35 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore , Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1747884116339411592== Content-Type: multipart/alternative; boundary=----------412esfLpOOAFOc8ROIILXq ------------412esfLpOOAFOc8ROIILXq Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider 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. 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. Hassan ------------412esfLpOOAFOc8ROIILXq Content-Type: multipart/related; boundary=----------412esfLpOOAFOcwQoApQSQ ------------412esfLpOOAFOcwQoApQSQ Content-Type: text/html; charset=iso-8859-15 Content-ID: Content-Transfer-Encoding: Quoted-Printable On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider <ncoopride= r@yankeehacker.com> wrote:


= Thanks for the suggestion. I'm getting other audit events from sshd with= out restarting ssh. It's just the accept syscalls that do not show up un= til after I restart ssh:

type=3DSYSCALL msg= =3Daudit(1480714641.465:54): arch=3Dc000003e syscall=3D43 success=3Dyes = exit=3D5 a0=3D3 a1=3D7ffce3b031b0 a2=3D7ffce3b0319c a3=3D0 items=3D0 ppi= d=3D1 pid=3D2602 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsu= id=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D= "sshd" exe=3D"/usr/sbin/sshd" key=3D(null)

= I think that indicates the kernel is sending up audit messages. My quest= ion 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 ca= me up with one theory explaining it :

- accept = is a blocking syscall , it might be that sshd started and the syscall wa= s initiated before the audit rule was loaded. This would explain why you= see the event when restarting sshd.

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 amou= nts to when sshd is started.


Has= san
------------412esfLpOOAFOcwQoApQSQ-- ------------412esfLpOOAFOc8ROIILXq-- --===============1747884116339411592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1747884116339411592==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Re: Auditd misses accept syscalls from sshd Date: Sat, 03 Dec 2016 02:11:04 +0000 Message-ID: References: <3811129.XXtPaolnaT@x2> <3309840.oCxPxWEFuR@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3558291261381771717==" Return-path: In-Reply-To: <3309840.oCxPxWEFuR@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============3558291261381771717== Content-Type: multipart/alternative; boundary=94eb2c123566db38a40542b79183 --94eb2c123566db38a40542b79183 Content-Type: text/plain; charset=UTF-8 Hi! It sounds like I'm missing something obvious! On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb wrote: > Hello, > > Addressing a couple obvious things here... > > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote: > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb wrote: > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. > > > > > > Its not auditd, the kernel does all the work. Auditd acts a lot like a > > > specialized syslog. :-) > > > > > > > I tried versions 2.3.2 and 2.4.5 of the daemon > > Support was not added until 2.5. > Support for what? Auditing the accept syscall? What do you mean by "support?" Those are auditd versions that I'm talking about. Is that what you mean? Sorry if I was not clear. What did it do with accept syscalls before then? I do not see this reflected in the changelog https://people.redhat.com/sgrubb/audit/ChangeLog > > > with kernel versions 3.13.0-96 > > Definitely won't support it. > Support what? > > > > and 4.4.0-47. > > The feature landed in 4.3, so 4.4 should have it. However, you need audit > 2.5 > or later to use the kernel feature. > What feature are you talking about? This sounds like it could be the issue, but I am not sure to what you are actually referring. > > I just tried again and had the same problem: > > > > vagrant@vagrant:~$ uname -a > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > Try pairing that with a newer auditd so that auditctl has the support to > load > the rule. > I'll check this out. My initial attempts to compile more recent versions than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are probably personal problems. > -Steve > > > That's a newer version than I have on my Ubuntu 16 VM, which does > > demonstrate the problem. It's also strange that restarting ssh then makes > > the accept syscall events show up. Other sshd syscalls show up in auditd > > before and after the ssh restart. > --94eb2c123566db38a40542b79183 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi! It sounds like I'm missing something obvious!
<= br>
On Fri, Dec 2, 2016 at 5:13 = PM Steve Grubb <sgrubb@redhat.com> wrote:
Hello,

Addressing a couple obvious things here...

On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote:
> On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat.com&g= t; wrote:
> > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote= :
> > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14.<= br class=3D"gmail_msg"> > >
> > Its not auditd, the kernel does all the work. Auditd acts a lot l= ike a
> > specialized syslog.=C2=A0 :-)
> >
> > > I tried versions 2.3.2 and 2.4.5 of the daemon

Support was not added until 2.5.
<= br>
Support for what? Auditing the accept syscall? What do you me= an by "support?" Those are auditd versions that I'm talking a= bout. Is that what you mean? Sorry if I was not clear. What did it do with = accept syscalls before then? I do not see this reflected in the changelog


> > > with kernel versions 3.13.0-96

Definitely won't support it.
<= br>
Support what?
=C2=A0
> > > and 4.4.0-47.

The feature landed in 4.3, so 4.4 should have it. However, you need audit 2= .5
or later to use the kernel feature.

What feature are you talking about? This sounds like it co= uld be the issue, but I am not sure to what you are actually referring.
=C2=A0
>=C2=A0 I just tried again and had the same problem:
>
> vagrant@vagrant:~$ uname -a
> Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22= :30
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Try pairing that with a newer auditd so that auditctl has the support to lo= ad
the rule.

I'll = check this out. My initial attempts to compile more recent versions than 2.= 4.5 on the newer kernel in Ubuntu 14 had issues, but those are probably per= sonal problems.=C2=A0
=C2=A0
-Steve

> That's a newer version than I have on my Ubuntu 16 VM, which does<= br class=3D"gmail_msg"> > demonstrate the problem. It's also strange that restarting ssh the= n makes
> the accept syscall events show up. Other sshd syscalls show up in audi= td
> before and after the ssh restart.
=

=C2=A0
--94eb2c123566db38a40542b79183-- --===============3558291261381771717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3558291261381771717==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Re: Auditd misses accept syscalls from sshd Date: Sat, 03 Dec 2016 02:15:35 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4204354948157620113==" Return-path: Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB32Flsx027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Dec 2016 21:15:47 -0500 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 849A18F278 for ; Sat, 3 Dec 2016 02:15:46 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id b35so299012744uaa.3 for ; Fri, 02 Dec 2016 18:15:46 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Hassan Sultan Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============4204354948157620113== Content-Type: multipart/alternative; boundary=94eb2c04cabce090340542b7a15b --94eb2c04cabce090340542b7a15b Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 6:44 PM Hassan Sultan wrote: > On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider < > ncooprider@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. > > 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. > > > Hassan > After I restart the ssh service I get an accept call every time I try to ssh into the box, whereas before I restart the ssh service I get no events. That does not conform with my mental model of how this would work, but I wouldn't be asking this question if my mental model was correct! Thanks for the hypothesis and tip, plus the original question! --94eb2c04cabce090340542b7a15b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2,= 2016 at 6:44 PM Hassan Sultan <= hsultan@thefroid.net> wrote:
On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Coopri= der <ncooprider@yankeehacker.com> wrote:


Thanks for the suggestion. I'm get= ting 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=3DSYSCALL msg=3Daudit(1480714641.465:54): arch= =3Dc000003e syscall=3D43 success=3Dyes exit=3D5 a0=3D3 a1=3D7ffce3b031b0 a2= =3D7ffce3b0319c a3=3D0 items=3D0 ppid=3D1 pid=3D2602 auid=3D4294967295 uid= =3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D= (none) ses=3D4294967295 comm=3D"sshd" exe=3D"/usr/sbin/sshd&= quot; key=3D(null)
I think that indicates= the kernel is sending up audit messages. My question is why the above mess= age 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 aud= it rule was loaded. This would explain why you see the event when restartin= g sshd.

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.


Hassan

After I restart the ssh= service I get an accept call every time I try to ssh into the box, whereas= before I restart the ssh service I get no events. That does not conform wi= th my mental model of how this would work, but I wouldn't be asking thi= s question if my mental model was correct!

Thanks = for the hypothesis and tip, plus the original question!=C2=A0
--94eb2c04cabce090340542b7a15b-- --===============4204354948157620113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4204354948157620113==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditd misses accept syscalls from sshd Date: Sat, 03 Dec 2016 12:39:51 -0500 Message-ID: <1777888.9thD5geisr@x2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday, December 2, 2016 3:44:35 PM EST Hassan Sultan wrote: > On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditd misses accept syscalls from sshd Date: Sat, 03 Dec 2016 12:47:06 -0500 Message-ID: <7841465.GifJlmNWiC@x2> References: <3309840.oCxPxWEFuR@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Saturday, December 3, 2016 2:11:04 AM EST Nathan Cooprider wrote: > Hi! It sounds like I'm missing something obvious! > > On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb wrote: > > Hello, > > > > Addressing a couple obvious things here... > > > > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote: > > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb wrote: > > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > > > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. > > > > > > > > Its not auditd, the kernel does all the work. Auditd acts a lot like a > > > > specialized syslog. :-) > > > > > > > > > I tried versions 2.3.2 and 2.4.5 of the daemon > > > > Support was not added until 2.5. > > Support for what? Audit by executable. In the example that I gave I showed the syntax for how you would audit accept only for sshd. I presume that you are not auditing accept across the whole system. What rule are you using to audit accept? > Auditing the accept syscall? What do you mean by "support?" Those are auditd > versions that I'm talking about. Is that what you mean? Sorry if I was not > clear. What did it do with accept syscalls before then? I do not see this > reflected in the changelog Let's take a look at how you are auditing it and maybe that will explain a few things. Also, does Ubuntu 14 use upstart or systemd? And perhaps for good measure include just 1 event when it does work. -Steve > https://people.redhat.com/sgrubb/audit/ChangeLog > > > > > with kernel versions 3.13.0-96 > > > > Definitely won't support it. > > Support what? > > > > > > and 4.4.0-47. > > > > The feature landed in 4.3, so 4.4 should have it. However, you need audit > > 2.5 > > or later to use the kernel feature. > > What feature are you talking about? This sounds like it could be the issue, > but I am not sure to what you are actually referring. > > > > I just tried again and had the same problem: > > > vagrant@vagrant:~$ uname -a > > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 > > > 19:22:30 > > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > > > Try pairing that with a newer auditd so that auditctl has the support to > > load > > the rule. > > I'll check this out. My initial attempts to compile more recent versions > than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are > probably personal problems. > > > -Steve > > > > > That's a newer version than I have on my Ubuntu 16 VM, which does > > > demonstrate the problem. It's also strange that restarting ssh then > > > makes > > > the accept syscall events show up. Other sshd syscalls show up in auditd > > > before and after the ssh restart. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Cooprider Subject: Re: Auditd misses accept syscalls from sshd Date: Mon, 05 Dec 2016 16:42:14 +0000 Message-ID: References: <3309840.oCxPxWEFuR@x2> <7841465.GifJlmNWiC@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0032499635234048122==" Return-path: In-Reply-To: <7841465.GifJlmNWiC@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0032499635234048122== Content-Type: multipart/alternative; boundary=94eb2c12356609bc020542ebf93c --94eb2c12356609bc020542ebf93c Content-Type: text/plain; charset=UTF-8 On Sat, Dec 3, 2016 at 12:47 PM Steve Grubb wrote: > On Saturday, December 3, 2016 2:11:04 AM EST Nathan Cooprider wrote: > > Hi! It sounds like I'm missing something obvious! > > > > On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb wrote: > > > Hello, > > > > > > Addressing a couple obvious things here... > > > > > > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote: > > > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb > wrote: > > > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote: > > > > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14. > > > > > > > > > > Its not auditd, the kernel does all the work. Auditd acts a lot > like a > > > > > specialized syslog. :-) > > > > > > > > > > > I tried versions 2.3.2 and 2.4.5 of the daemon > > > > > > Support was not added until 2.5. > > > > Support for what? > > Audit by executable. In the example that I gave I showed the syntax for how > you would audit accept only for sshd. I presume that you are not auditing > accept across the whole system. What rule are you using to audit accept? > Here's what I have: vagrant@vagrant:~$ uname -a Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux vagrant@vagrant:~$ sudo auditctl -l No rules vagrant@vagrant:~$ sudo auditctl -a exit,always -F arch=b64 -S accept vagrant@vagrant:~$ sudo auditctl -l LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=accept For my case, I am auditing accept syscalls across the whole system. I want to look for when that syscall occurs in my log and alert on it. > > Auditing the accept syscall? What do you mean by "support?" Those are > auditd > > versions that I'm talking about. Is that what you mean? Sorry if I was > not > > clear. What did it do with accept syscalls before then? I do not see this > > reflected in the changelog > > Let's take a look at how you are auditing it and maybe that will explain a > few > things. Also, does Ubuntu 14 use upstart or systemd? And perhaps for good > measure include just 1 event when it does work. > Ubuntu 14 uses upstart. Specifically, my VM is using upstart 1.12.1. I should note that I tried this on CentOS 6 this morning and it did not have this issue. Here's the output from audit for my test, with <> tags indicating when something happened in another terminal: vagrant@vagrant:~$ sudo auditd -f Config file /etc/audit/auditd.conf opened for parsing log_file_parser called with: /var/log/audit/audit.log log_format_parser called with: RAW log_group_parser called with: root priority_boost_parser called with: 4 flush_parser called with: INCREMENTAL freq_parser called with: 20 num_logs_parser called with: 5 qos_parser called with: lossy dispatch_parser called with: /sbin/audispd name_format_parser called with: NONE max_log_size_parser called with: 6 max_log_size_action_parser called with: ROTATE space_left_parser called with: 75 space_action_parser called with: SYSLOG action_mail_acct_parser called with: root admin_space_left_parser called with: 50 admin_space_left_action_parser called with: SUSPEND disk_full_action_parser called with: SUSPEND disk_error_action_parser called with: SUSPEND tcp_listen_queue_parser called with: 5 Listener support is not enabled, ignoring value at line 26 tcp_max_per_addr_parser called with: 1 Listener support is not enabled, ignoring value at line 27 tcp_client_max_idle_parser called with: 0 Listener support is not enabled, ignoring value at line 29 enable_krb5_parser called with: no krb5_principal_parser called with: auditd Started dispatcher: /sbin/audispd pid: 20106 type=DAEMON_START msg=audit(1480954770.929:9566): auditd start, ver=2.3.2 format=raw kernel=4.4.0-51-generic auid=1000 pid=20104 subj=unconfined res=success config_manager init complete Init complete, auditd 2.3.2 listening for events (startup state enable) type=USER_LOGIN msg=audit(1480954826.056:416): pid=20108 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct="vagrant" exe="/usr/sbin/sshd" hostname=? addr=10.0.2.2 terminal=sshd res=failed' type=USER_ACCT msg=audit(1480954826.064:417): pid=20108 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=CRED_ACQ msg=audit(1480954826.068:418): pid=20108 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=LOGIN msg=audit(1480954826.068:419): pid=20108 uid=0 old-auid=4294967295 auid=1000 old-ses=4294967295 ses=6 res=1 type=USER_START msg=audit(1480954826.404:420): pid=20108 uid=0 auid=1000 ses=6 msg='op=PAM:session_open acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=CRED_ACQ msg=audit(1480954826.404:421): pid=20175 uid=0 auid=1000 ses=6 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=USER_LOGIN msg=audit(1480954826.404:422): pid=20108 uid=0 auid=1000 ses=6 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=/dev/pts/1 res=success' type=USER_START msg=audit(1480954850.688:423): pid=20190 uid=0 auid=1000 ses=6 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' type=USER_END msg=audit(1480954850.720:424): pid=20190 uid=0 auid=1000 ses=6 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' type=SYSCALL msg=audit(1480954895.508:425): arch=c000003e *syscall=43* success=yes exit=5 a0=3 a1=7ffd736315c0 a2=7ffd736315ac a3=0 items=0 ppid=1 pid=20204 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) type=SOCKADDR msg=audit(1480954895.508:425): saddr=0200CE760A0002020000000000000000 type=UNKNOWN[1327] msg=audit(1480954895.508:425): proctitle=2F7573722F7362696E2F73736864002D44 type=USER_LOGIN msg=audit(1480954895.524:426): pid=20206 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct="vagrant" exe="/usr/sbin/sshd" hostname=? addr=10.0.2.2 terminal=sshd res=failed' type=USER_ACCT msg=audit(1480954895.532:427): pid=20206 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=CRED_ACQ msg=audit(1480954895.536:428): pid=20206 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=LOGIN msg=audit(1480954895.536:429): pid=20206 uid=0 old-auid=4294967295 auid=1000 old-ses=4294967295 ses=7 res=1 type=USER_START msg=audit(1480954895.772:430): pid=20206 uid=0 auid=1000 ses=7 msg='op=PAM:session_open acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=CRED_ACQ msg=audit(1480954895.772:431): pid=20270 uid=0 auid=1000 ses=7 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success' type=USER_LOGIN msg=audit(1480954895.772:432): pid=20206 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=/dev/pts/3 res=success' -Steve > > > https://people.redhat.com/sgrubb/audit/ChangeLog > > > > > > > with kernel versions 3.13.0-96 > > > > > > Definitely won't support it. > > > > Support what? > > > > > > > > and 4.4.0-47. > > > > > > The feature landed in 4.3, so 4.4 should have it. However, you need > audit > > > 2.5 > > > or later to use the kernel feature. > > > > What feature are you talking about? This sounds like it could be the > issue, > > but I am not sure to what you are actually referring. > > > > > > I just tried again and had the same problem: > > > > vagrant@vagrant:~$ uname -a > > > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 > > > > 19:22:30 > > > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > > > > > Try pairing that with a newer auditd so that auditctl has the support > to > > > load > > > the rule. > > > > I'll check this out. My initial attempts to compile more recent versions > > than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are > > probably personal problems. > > > > > -Steve > > > > > > > That's a newer version than I have on my Ubuntu 16 VM, which does > > > > demonstrate the problem. It's also strange that restarting ssh then > > > > makes > > > > the accept syscall events show up. Other sshd syscalls show up in > auditd > > > > before and after the ssh restart. > --94eb2c12356609bc020542ebf93c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 3,= 2016 at 12:47 PM Steve Grubb <sgru= bb@redhat.com> wrote:
On Sat= urday, December 3, 2016 2:11:04 AM EST Nathan Cooprider wrote:
> Hi! It sounds like I'm missing something obvious!
>
> On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb <sgrubb@redhat.com&g= t; wrote:
> > Hello,
> >
> > Addressing a couple obvious things here...
> >
> > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote= :
> > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat= .com> wrote:
> > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Coopr= ider wrote:
> > > > > Auditd seems to miss accept syscalls from ssh on U= buntu 14.
> > > >
> > > > Its not auditd, the kernel does all the work. Auditd ac= ts a lot like a
> > > > specialized syslog.=C2=A0 :-)
> > > >
> > > > > I tried versions 2.3.2 and 2.4.5 of the daemon
> >
> > Support was not added until 2.5.
>
> Support for what?

Audit by executable. In the example that I gave I showed the syntax for how=
you would audit accept only for sshd. I presume that you are not auditing accept across the whole system. What rule are you using to audit accept?

Here's what I hav= e:

vagrant@vagrant:~$ uname -a
Linu= x vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 UTC 2= 016 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant:~$ sudo auditc= tl -l
No rules
vagrant@vagrant:~$ sudo auditctl -a exit= ,always -F arch=3Db64 -S accept
vagrant@vagrant:~$ sudo auditctl = -l
LIST_RULES: exit,always arch=3D3221225534 (0xc000003e) syscall= =3Daccept

For my case, I am auditing accept = syscalls across the whole system. I want to look for when that syscall occu= rs in my log and alert on it.
=C2=A0
> Auditing the accept syscall? What do you mean by "support?" = Those are auditd
> versions that I'm talking about. Is that what you mean? Sorry if I= was not
> clear. What did it do with accept syscalls before then? I do not see t= his
> reflected in the changelog

Let's take a look at how you are auditing it and maybe that will explai= n a few
things. Also, does Ubuntu 14 use upstart or systemd? And perhaps for good measure include just 1 event when it does work.

Ubuntu 14 uses upstart. Specifically, my VM is= using upstart 1.12.1.

I should note that I t= ried this on CentOS 6 this morning and it did not have this issue.=C2=A0

Here's the output from audit for my test, = with <> tags indicating when something happened in another terminal:<= /div>

vagrant@vagrant:~$ sudo auditd -f
C= onfig file /etc/audit/auditd.conf opened for parsing
log_file_par= ser called with: /var/log/audit/audit.log
log_format_parser calle= d with: RAW
log_group_parser called with: root
priority= _boost_parser called with: 4
flush_parser called with: INCREMENTA= L
freq_parser called with: 20
num_logs_parser called wi= th: 5
qos_parser called with: lossy
dispatch_parser cal= led with: /sbin/audispd
name_format_parser called with: NONE
max_log_size_parser called with: 6
max_log_size_action_pars= er called with: ROTATE
space_left_parser called with: 75
space_action_parser called with: SYSLOG
action_mail_acct_parser= called with: root
admin_space_left_parser called with: 50
<= div>admin_space_left_action_parser called with: SUSPEND
disk_full= _action_parser called with: SUSPEND
disk_error_action_parser call= ed with: SUSPEND
tcp_listen_queue_parser called with: 5
Listener support is not enabled, ignoring value at line 26
tcp_m= ax_per_addr_parser called with: 1
Listener support is not enabled= , ignoring value at line 27
tcp_client_max_idle_parser called wit= h: 0
Listener support is not enabled, ignoring value at line 29
enable_krb5_parser called with: no
krb5_principal_parser= called with: auditd
Started dispatcher: /sbin/audispd pid: 20106=
type=3DDAEMON_START msg=3Daudit(1480954770.929:9566): auditd sta= rt, ver=3D2.3.2 format=3Draw kernel=3D4.4.0-51-generic auid=3D1000 pid=3D20= 104 subj=3Dunconfined =C2=A0res=3Dsuccess
config_manager init com= plete
Init complete, auditd 2.3.2 listening for events (startup s= tate enable)
<An ssh log in before restarting ssh>
type=3DUSER_LOGIN msg=3Daudit(1480954826.056:416): pid=3D20108 uid=3D0 au= id=3D4294967295 ses=3D4294967295 msg=3D'op=3Dlogin acct=3D"vagrant= " exe=3D"/usr/sbin/sshd" hostname=3D? addr=3D10.0.2.2 termin= al=3Dsshd res=3Dfailed'
type=3DUSER_ACCT msg=3Daudit(14809548= 26.064:417): pid=3D20108 uid=3D0 auid=3D4294967295 ses=3D4294967295 msg=3D&= #39;op=3DPAM:accounting acct=3D"vagrant" exe=3D"/usr/sbin/ss= hd" hostname=3D10.0.2.2 addr=3D10.0.2.2 terminal=3Dssh res=3Dsuccess&#= 39;
type=3DCRED_ACQ msg=3Daudit(1480954826.068:418): pid=3D20108 = uid=3D0 auid=3D4294967295 ses=3D4294967295 msg=3D'op=3DPAM:setcred acct= =3D"vagrant" exe=3D"/usr/sbin/sshd" hostname=3D10.0.2.2= addr=3D10.0.2.2 terminal=3Dssh res=3Dsuccess'
type=3DLOGIN m= sg=3Daudit(1480954826.068:419): pid=3D20108 uid=3D0 old-auid=3D4294967295 a= uid=3D1000 old-ses=3D4294967295 ses=3D6 res=3D1
type=3DUSER_START= msg=3Daudit(1480954826.404:420): pid=3D20108 uid=3D0 auid=3D1000 ses=3D6 m= sg=3D'op=3DPAM:session_open acct=3D"vagrant" exe=3D"/usr= /sbin/sshd" hostname=3D10.0.2.2 addr=3D10.0.2.2 terminal=3Dssh res=3Ds= uccess'
type=3DCRED_ACQ msg=3Daudit(1480954826.404:421): pid= =3D20175 uid=3D0 auid=3D1000 ses=3D6 msg=3D'op=3DPAM:setcred acct=3D&qu= ot;vagrant" exe=3D"/usr/sbin/sshd" hostname=3D10.0.2.2 addr= =3D10.0.2.2 terminal=3Dssh res=3Dsuccess'
type=3DUSER_LOGIN m= sg=3Daudit(1480954826.404:422): pid=3D20108 uid=3D0 auid=3D1000 ses=3D6 msg= =3D'op=3Dlogin id=3D1000 exe=3D"/usr/sbin/sshd" hostname=3D10= .0.2.2 addr=3D10.0.2.2 terminal=3D/dev/pts/1 res=3Dsuccess'
&= lt;Restarting ssh>
type=3DUSER_START msg=3Daudit(1480954850.68= 8:423): pid=3D20190 uid=3D0 auid=3D1000 ses=3D6 msg=3D'op=3DPAM:session= _open acct=3D"root" exe=3D"/usr/bin/sudo" hostname=3D? = addr=3D? terminal=3D/dev/pts/1 res=3Dsuccess'
type=3DUSER_END= msg=3Daudit(1480954850.720:424): pid=3D20190 uid=3D0 auid=3D1000 ses=3D6 m= sg=3D'op=3DPAM:session_close acct=3D"root" exe=3D"/usr/b= in/sudo" hostname=3D? addr=3D? terminal=3D/dev/pts/1 res=3Dsuccess'= ;
<After restarting ssh, so the accept event comes in now when= I log in>
type=3DSYSCALL msg=3Daudit(1480954895.508:425): arc= h=3Dc000003e syscall=3D43 success=3Dyes exit=3D5 a0=3D3 a1=3D7ffd736= 315c0 a2=3D7ffd736315ac a3=3D0 items=3D0 ppid=3D1 pid=3D20204 auid=3D429496= 7295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D= 0 tty=3D(none) ses=3D4294967295 comm=3D"sshd" exe=3D"/usr/sb= in/sshd" key=3D(null)
type=3DSOCKADDR msg=3Daudit(1480954895= .508:425): saddr=3D0200CE760A0002020000000000000000
type=3DUNKNOW= N[1327] msg=3Daudit(1480954895.508:425): proctitle=3D2F7573722F7362696E2F73= 736864002D44
type=3DUSER_LOGIN msg=3Daudit(1480954895.524:426): p= id=3D20206 uid=3D0 auid=3D4294967295 ses=3D4294967295 msg=3D'op=3Dlogin= acct=3D"vagrant" exe=3D"/usr/sbin/sshd" hostname=3D? a= ddr=3D10.0.2.2 terminal=3Dsshd res=3Dfailed'
type=3DUSER_ACCT= msg=3Daudit(1480954895.532:427): pid=3D20206 uid=3D0 auid=3D4294967295 ses= =3D4294967295 msg=3D'op=3DPAM:accounting acct=3D"vagrant" exe= =3D"/usr/sbin/sshd" hostname=3D10.0.2.2 addr=3D10.0.2.2 terminal= =3Dssh res=3Dsuccess'
type=3DCRED_ACQ msg=3Daudit(1480954895.= 536:428): pid=3D20206 uid=3D0 auid=3D4294967295 ses=3D4294967295 msg=3D'= ;op=3DPAM:setcred acct=3D"vagrant" exe=3D"/usr/sbin/sshd&quo= t; hostname=3D10.0.2.2 addr=3D10.0.2.2 terminal=3Dssh res=3Dsuccess'
type=3DLOGIN msg=3Daudit(1480954895.536:429): pid=3D20206 uid=3D0 o= ld-auid=3D4294967295 auid=3D1000 old-ses=3D4294967295 ses=3D7 res=3D1
=
type=3DUSER_START msg=3Daudit(1480954895.772:430): pid=3D20206 uid=3D0= auid=3D1000 ses=3D7 msg=3D'op=3DPAM:session_open acct=3D"vagrant&= quot; exe=3D"/usr/sbin/sshd" hostname=3D10.0.2.2 addr=3D10.0.2.2 = terminal=3Dssh res=3Dsuccess'
type=3DCRED_ACQ msg=3Daudit(148= 0954895.772:431): pid=3D20270 uid=3D0 auid=3D1000 ses=3D7 msg=3D'op=3DP= AM:setcred acct=3D"vagrant" exe=3D"/usr/sbin/sshd" host= name=3D10.0.2.2 addr=3D10.0.2.2 terminal=3Dssh res=3Dsuccess'
type=3DUSER_LOGIN msg=3Daudit(1480954895.772:432): pid=3D20206 uid=3D0 aui= d=3D1000 ses=3D7 msg=3D'op=3Dlogin id=3D1000 exe=3D"/usr/sbin/sshd= " hostname=3D10.0.2.2 addr=3D10.0.2.2 terminal=3D/dev/pts/3 res=3Dsucc= ess'

-Steve
> https://people.redhat.com/s= grubb/audit/ChangeLog
>
> > > > with kernel versions 3.13.0-96
> >
> > Definitely won't support it.
>
> Support what?
>
> > > > > and 4.4.0-47.
> >
> > The feature landed in 4.3, so 4.4 should have it. However, you ne= ed audit
> > 2.5
> > or later to use the kernel feature.
>
> What feature are you talking about? This sounds like it could be the i= ssue,
> but I am not sure to what you are actually referring.
>
> > >=C2=A0 I just tried again and had the same problem:
> > > vagrant@vagrant:~$ uname -a
> > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu No= v 24
> > > 19:22:30
> > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Try pairing that with a newer auditd so that auditctl has the sup= port to
> > load
> > the rule.
>
> I'll check this out. My initial attempts to compile more recent ve= rsions
> than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are<= br class=3D"gmail_msg"> > probably personal problems.
>
> > -Steve
> >
> > > That's a newer version than I have on my Ubuntu 16 VM, w= hich does
> > > demonstrate the problem. It's also strange that restarti= ng ssh then
> > > makes
> > > the accept syscall events show up. Other sshd syscalls show = up in auditd
> > > before and after the ssh restart.
--94eb2c12356609bc020542ebf93c-- --===============0032499635234048122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0032499635234048122==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditd misses accept syscalls from sshd Date: Mon, 05 Dec 2016 17:44:06 -0500 Message-ID: <2052748.Z1A4H7y1HO@x2> References: <7841465.GifJlmNWiC@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nathan Cooprider Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, December 5, 2016 4:42:14 PM EST Nathan Cooprider wrote: > On Sat, Dec 3, 2016 at 12:47 PM Steve Grubb wrote: > > > > Support was not added until 2.5. > > > > > > Support for what? > > > > Audit by executable. In the example that I gave I showed the syntax for > > how you would audit accept only for sshd. I presume that you are not > > auditing accept across the whole system. What rule are you using to audit > > accept? > > Here's what I have: > > vagrant@vagrant:~$ uname -a > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30 > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > vagrant@vagrant:~$ sudo auditctl -l > No rules > vagrant@vagrant:~$ sudo auditctl -a exit,always -F arch=b64 -S accept > vagrant@vagrant:~$ sudo auditctl -l > LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=accept > > For my case, I am auditing accept syscalls across the whole system. I want > to look for when that syscall occurs in my log and alert on it. OK. I was thinking that perhaps you had the rule qualified with -F auid>=500 -F auid!=-1 to detect user originating events and the restart (because its upstart) would put your auid into sshd's and then you were successful in auditing. If the above rule is in fact what you are auditing with, and you have auidit=1 on your grub kernel boot commandline, then I am out of guesses. Sounds like a problem unique to your kernel since you have found kernels that work fine. -Steve