From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: aulast only displaying reboot pseudo-users Date: Wed, 04 Jun 2014 19:04:52 -0400 Message-ID: <1487476.CjeIAT3yaP@x2> References: <20140605000405.687f6ad7@fornost.bigon.be> <11400116.CdDq4vnLvl@x2> <20140605004239.1724bbe8@fornost.bigon.be> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20140605004239.1724bbe8@fornost.bigon.be> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Laurent Bigonville Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday, June 05, 2014 12:42:39 AM Laurent Bigonville wrote: > Le Wed, 04 Jun 2014 18:23:29 -0400, > = > Steve Grubb a =E9crit : > > On Thursday, June 05, 2014 12:04:05 AM Laurent Bigonville wrote: > > > On my machine with audit 2.3.6 the following call to aulast is only > > > displaying the "reboot" pseudo-users and not the actual logins: > > > = > > > ausearch --start this-month --raw | aulast --stdin > > > = > > > Passing the "--bad" option to aulast, seems to correctly return the > > > failed login attempt. > > > = > > > Also, adding the login name to the aulast command doesn't seems to > > > work at all even with the --bad option. > > > = > > > OTOH, the aulastlog command seems to work as expected. > > > = > > > An idea? > > = > > Would this happen to be a system with a recent GDM and systemd? If > > = > > so, they are known to be messing up the audit trail. I am trying to > > write a system validation test suite to spot issues like this. If you > > look at gdm, its sending duplicate events. Systemd events don't make > > it to audit all the time. Its a mess on the desktop right now. > = > Yes indeed I'm running gdm 3.12 and systemd 208. > = > But I'm not seeing anything in aulast output when I'm login in on a tty. > = > ausearch is however giving me this: > = > bigon@fornost:~$ sudo ausearch -m ALL -ts 00:35|grep test > type=3DUSER_AUTH msg=3Daudit(1401921359.577:1394): pid=3D15760 uid=3D0 > auid=3D4294967295 ses=3D4294967295 > subj=3Dsystem_u:system_r:local_login_t:s0-s0:c0.c1023 > msg=3D'op=3DPAM:authentication acct=3D"test" exe=3D"/bin/login" hostname= =3D? addr=3D? > terminal=3D/dev/tty1 res=3Dsuccess' = > type=3DUSER_ACCT msg=3Daudit(1401921359.577:1395): pid=3D15760 uid=3D0 > auid=3D4294967295 ses=3D4294967295 subj=3Dsystem_u:system_r:local_login_t= :s0- > s0:c0.c1023 msg=3D'op=3DPAM:accounting acct=3D"test" exe=3D"/bin/login" h= ostname=3D? > addr=3D?> terminal=3D/dev/tty1 res=3Dsuccess' You are missing a type=3DLOGIN event right here. If you do a "cat = /proc/self/loginuid" and its set to something besides -1, we have a kernel = bug. -Steve > type=3DUSER_START msg=3Daudit(1401921359.617:1403): pid=3D15760 uid=3D0 a= uid=3D1002 > ses=3D66 subj=3Dsystem_u:system_r:local_login_t:s0-s0:c0.c1023 > msg=3D'op=3DPAM:session_open acct=3D"test" exe=3D"/bin/login" hostname=3D= ? addr=3D? > terminal=3D/dev/tty1 res=3Dsuccess' type=3DCRED_ACQ > msg=3Daudit(1401921359.617:1404): pid=3D15760 uid=3D0 auid=3D1002 ses=3D66 > subj=3Dsystem_u:system_r:local_login_t:s0-s0:c0.c1023 msg=3D'op=3DPAM:set= cred > acct=3D"test" exe=3D"/bin/login" hostname=3D? addr=3D? terminal=3D/dev/tt= y1 > res=3Dsuccess' type=3DUSER_LOGIN msg=3Daudit(1401921359.617:1405): pid=3D= 15760 > uid=3D0 auid=3D1002 ses=3D66 subj=3Dsystem_u:system_r:local_login_t:s0-s0= :c0.c1023 > msg=3D'op=3Dlogin acct=3D"test" exe=3D"/bin/login" hostname=3D? addr=3D? > terminal=3D/dev/tty1 res=3Dsuccess' type=3DUSER_END > msg=3Daudit(1401921360.221:1408): pid=3D15760 uid=3D0 auid=3D1002 ses=3D66 > subj=3Dsystem_u:system_r:local_login_t:s0-s0:c0.c1023 > msg=3D'op=3DPAM:session_close acct=3D"test" exe=3D"/bin/login" hostname= =3D? addr=3D? > terminal=3D/dev/tty1 res=3Dsuccess'