5:04 p.m.
Hello,
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?
Cheers,
Laurent Bigonville
5:23 p.m.
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.
-Steve
5:42 p.m.
Le Wed, 04 Jun 2014 18:23:29 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
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=USER_AUTH msg=audit(1401921359.577:1394): pid=15760 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=PAM:authentication acct="test" exe="/bin/login" hostname=?
addr=? terminal=/dev/tty1 res=success'
type=USER_ACCT msg=audit(1401921359.577:1395): pid=15760 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=PAM:accounting acct="test" exe="/bin/login" hostname=?
addr=? terminal=/dev/tty1 res=success'
type=USER_START msg=audit(1401921359.617:1403): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open
acct="test" exe="/bin/login" hostname=? addr=? terminal=/dev/tty1
res=success'
type=CRED_ACQ msg=audit(1401921359.617:1404): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred
acct="test" exe="/bin/login" hostname=? addr=? terminal=/dev/tty1
res=success'
type=USER_LOGIN msg=audit(1401921359.617:1405): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login
acct="test" exe="/bin/login" hostname=? addr=? terminal=/dev/tty1
res=success'
type=USER_END msg=audit(1401921360.221:1408): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_close
acct="test" exe="/bin/login" hostname=? addr=? terminal=/dev/tty1
res=success'
6:04 p.m.
On Thursday, June 05, 2014 12:42:39 AM Laurent Bigonville wrote:
Le Wed, 04 Jun 2014 18:23:29 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
> 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=USER_AUTH msg=audit(1401921359.577:1394): pid=15760 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=PAM:authentication acct="test" exe="/bin/login"
hostname=? addr=?
terminal=/dev/tty1 res=success'
type=USER_ACCT msg=audit(1401921359.577:1395): pid=15760 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-
s0:c0.c1023 msg='op=PAM:accounting acct="test" exe="/bin/login"
hostname=?
addr=?> terminal=/dev/tty1 res=success'
You are missing a type=LOGIN 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=USER_START msg=audit(1401921359.617:1403): pid=15760 uid=0
auid=1002
ses=66 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=PAM:session_open acct="test" exe="/bin/login" hostname=?
addr=?
terminal=/dev/tty1 res=success' type=CRED_ACQ
msg=audit(1401921359.617:1404): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred
acct="test" exe="/bin/login" hostname=? addr=? terminal=/dev/tty1
res=success' type=USER_LOGIN msg=audit(1401921359.617:1405): pid=15760
uid=0 auid=1002 ses=66 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=login acct="test" exe="/bin/login" hostname=? addr=?
terminal=/dev/tty1 res=success' type=USER_END
msg=audit(1401921360.221:1408): pid=15760 uid=0 auid=1002 ses=66
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
msg='op=PAM:session_close acct="test" exe="/bin/login" hostname=?
addr=?
terminal=/dev/tty1 res=success'
12:34 p.m.
Le Wed, 04 Jun 2014 19:04:52 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
On Thursday, June 05, 2014 12:42:39 AM Laurent Bigonville wrote:
> Le Wed, 04 Jun 2014 18:23:29 -0400,
>
> Steve Grubb <sgrubb(a)redhat.com> a écrit :
> > 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=USER_AUTH msg=audit(1401921359.577:1394): pid=15760 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023
> msg='op=PAM:authentication acct="test" exe="/bin/login"
hostname=?
> addr=? terminal=/dev/tty1 res=success'
> type=USER_ACCT msg=audit(1401921359.577:1395): pid=15760 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:local_login_t:s0- s0:c0.c1023
> msg='op=PAM:accounting acct="test" exe="/bin/login"
hostname=?
> addr=?> terminal=/dev/tty1 res=success'
You are missing a type=LOGIN event right here. If you do a "cat
/proc/self/loginuid" and its set to something besides -1, we have a
kernel bug.
Actually, my grepping was wrong, I'm seeing this the following line too:
type=LOGIN msg=audit(1401921359.597:1397): pid=15760 uid=0 old-auid=4294967295
new-auid=1002 old-ses=4294967295 new-ses=66 res=1
6:53 a.m.
Le Thu, 5 Jun 2014 19:34:04 +0200,
Laurent Bigonville <bigon(a)debian.org> a écrit :
Le Wed, 04 Jun 2014 19:04:52 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
[...]
> You are missing a type=LOGIN event right here. If you do a
"cat
> /proc/self/loginuid" and its set to something besides -1, we have a
> kernel bug.
>
Actually, my grepping was wrong, I'm seeing this the following line
too:
type=LOGIN msg=audit(1401921359.597:1397): pid=15760 uid=0
old-auid=4294967295 new-auid=1002 old-ses=4294967295 new-ses=66 res=1
Any idea here then?
Regarding "/proc/self/loginuid" it's always set to the uid of the user
here.
Looking at aulast code, I can see that there are differences for
kernels before or after 3.13. My machine is running 3.14, could this be
related?
Cheers,
Laurent Bigonville
4:20 p.m.
On Sat, 2014-06-14 at 13:53 +0200, Laurent Bigonville wrote:
Le Thu, 5 Jun 2014 19:34:04 +0200,
Laurent Bigonville <bigon(a)debian.org> a écrit :
> Le Wed, 04 Jun 2014 19:04:52 -0400,
> Steve Grubb <sgrubb(a)redhat.com> a écrit :
[...]
> > You are missing a type=LOGIN event right here. If you do a "cat
> > /proc/self/loginuid" and its set to something besides -1, we have a
> > kernel bug.
> >
>
>
> Actually, my grepping was wrong, I'm seeing this the following line
> too:
>
> type=LOGIN msg=audit(1401921359.597:1397): pid=15760 uid=0
> old-auid=4294967295 new-auid=1002 old-ses=4294967295 new-ses=66 res=1
Any idea here then?
Regarding "/proc/self/loginuid" it's always set to the uid of the user
here.
Looking at aulast code, I can see that there are differences for
kernels before or after 3.13. My machine is running 3.14, could this be
related?
Back in the olden-days we had:
"pid=%d uid=%u old auid=%u new auid=%u old ses=%u new ses=%u res=%d"
Which got complained about and resulted in:
commit 5ee9a75c9fdaebd3ac8176f9f5c73fdcd27c1ad1
Author: Richard Guy Briggs <rgb(a)redhat.com>
Date: Wed Dec 11 15:28:09 2013 -0500
audit: fix dangling keywords in audit_log_set_loginuid() output
Which gave us:
"pid=%d uid=%u old-auid=%u new-auid=%u old-ses=%u new-ses=%u res=%d"
And that is your record type.
Steve asked Richard to remove the "new-" from the fields which resulted
in
commit aa589a13b5d00d3c643ee4114d8cbc3addb4e99f
Author: Richard Guy Briggs <rgb(a)redhat.com>
Date: Mon Feb 24 12:31:11 2014 -0500
audit: remove superfluous new- prefix in AUDIT_LOGIN messages
Which got us to today's record type:
"pid=%d uid=%u subj=%s old-auid=%u auid=%u old-ses=%u ses=%u res=%d"
My guess is that userspace just throws away record where it doesn't find
the auid= and ses= and you kernel happens to live in those couple of
months were it had "new-ses" and "new-auid"
I'd call this a pretty clear userspace bug where it just completely
drops records, even if it can't parse them...
4:24 p.m.
On Mon, 2014-06-16 at 17:20 -0400, Eric Paris wrote:
I'd call this a pretty clear userspace bug where it just
completely
drops records, even if it can't parse them...
Definitely a userspace bug...
[root@localhost eparis]# ausearch -m login
<no matches>
[root@localhost eparis]# cat /var/log/audit/audit.log | grep "type=LOGIN" | wc
-l
14
[root@localhost eparis]# uname -a
Linux localhost.localdomain 3.14.4-200.fc20.x86_64 #1 SMP Tue May 13 13:51:08 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
[root@localhost eparis]# rpm -q audit
audit-2.3.7-1.fc20.x86_64
type=LOGIN msg=audit(1402952461.125:37289): pid=30708 uid=0 old-auid=4294967295 new-auid=0
old-ses=4294967295 new-ses=137 res=1
I get it that the parse doesn't know how to handle new-auid and new-ses,
but just dropping the record really seems like a bad idea to me...
-Eric
4:28 p.m.
On Mon, 2014-06-16 at 17:24 -0400, Eric Paris wrote:
On Mon, 2014-06-16 at 17:20 -0400, Eric Paris wrote:
> I'd call this a pretty clear userspace bug where it just completely
> drops records, even if it can't parse them...
Definitely a userspace bug...
[root@localhost eparis]# ausearch -m login
<no matches>
[root@localhost eparis]# cat /var/log/audit/audit.log | grep "type=LOGIN" | wc
-l
14
[root@localhost eparis]# uname -a
Linux localhost.localdomain 3.14.4-200.fc20.x86_64 #1 SMP Tue May 13 13:51:08 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
[root@localhost eparis]# rpm -q audit
audit-2.3.7-1.fc20.x86_64
type=LOGIN msg=audit(1402952461.125:37289): pid=30708 uid=0 old-auid=4294967295
new-auid=0 old-ses=4294967295 new-ses=137 res=1
I get it that the parse doesn't know how to handle new-auid and new-ses,
but just dropping the record really seems like a bad idea to me...
Ok, I'm finished chain e-mailing:
# cat /var/log/audit/audit.log | sed 's/new-auid/auid/' | sed
's/new-ses/ses/' | ausearch -m login
shows the records....
8:29 a.m.
On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
My guess is that userspace just throws away record where it
doesn't find
the auid= and ses= and you kernel happens to live in those couple of
months were it had "new-ses" and "new-auid"
Was this patch sent to stable? The audit code tries to handle the old way and
the new way:
https://fedorahosted.org/audit/browser/trunk/tools/aulast/aulast.c#L175
But I thought the patch went to stable to prevent breaking user space. This is
only one issue. I am seeing duplicate and missing events between systemd, gdm,
and lightdm.
I'd call this a pretty clear userspace bug where it just
completely
drops records, even if it can't parse them...
That theory can be tested by using:
ausearch --start this-week --debug > /dev/null
Anything that gets tossed out will be reported to stderr.
-Steve
9:09 a.m.
Le Tue, 17 Jun 2014 09:29:21 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
[...]
> I'd call this a pretty clear userspace bug where it just
completely
> drops records, even if it can't parse them...
That theory can be tested by using:
ausearch --start this-week --debug > /dev/null
Anything that gets tossed out will be reported to stderr.
I'm getting indeed quite a lot of skipped event:
Malformed event skipped, rc=7. type=LOGIN msg=audit(1402934401.462:1626): pid=1719 uid=0
old-auid=4294967295 new-auid=0 old-ses=4294967295 new-ses=121 res=1
-Steve
9:31 a.m.
On Tue, 17 Jun 2014 16:09:32 +0200
Laurent Bigonville <bigon(a)debian.org> wrote:
Le Tue, 17 Jun 2014 09:29:21 -0400,
Steve Grubb <sgrubb(a)redhat.com> a écrit :
> On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
[...]
> > I'd call this a pretty clear userspace bug where it just
> > completely drops records, even if it can't parse them...
>
> That theory can be tested by using:
>
> ausearch --start this-week --debug > /dev/null
>
> Anything that gets tossed out will be reported to stderr.
I'm getting indeed quite a lot of skipped event:
Malformed event skipped, rc=7. type=LOGIN
msg=audit(1402934401.462:1626): pid=1719 uid=0 old-auid=4294967295
new-auid=0 old-ses=4294967295 new-ses=121 res=1
This feel like 2 clear bugs.
1) The kernel records for LOGIN are 'malformed' in 3.14.
2) Userspace silently throws records which are 'malformed' away, instead
of just printing them...
ausearch -m LOGIN should be able to display these things...
9:55 a.m.
On 14/06/17, Eric Paris wrote:
On Tue, 17 Jun 2014 16:09:32 +0200
Laurent Bigonville <bigon(a)debian.org> wrote:
> Le Tue, 17 Jun 2014 09:29:21 -0400,
> Steve Grubb <sgrubb(a)redhat.com> a écrit :
>
> > On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
> [...]
> > > I'd call this a pretty clear userspace bug where it just
> > > completely drops records, even if it can't parse them...
> >
> > That theory can be tested by using:
> >
> > ausearch --start this-week --debug > /dev/null
> >
> > Anything that gets tossed out will be reported to stderr.
>
> I'm getting indeed quite a lot of skipped event:
>
> Malformed event skipped, rc=7. type=LOGIN
> msg=audit(1402934401.462:1626): pid=1719 uid=0 old-auid=4294967295
> new-auid=0 old-ses=4294967295 new-ses=121 res=1
This feel like 2 clear bugs.
1) The kernel records for LOGIN are 'malformed' in 3.14.
Yes. That's why it got fixed for 3.15.
5ee9a75 audit: fix dangling keywords in audit_log_set_loginuid() output
introduced it between 3.13 and 3.14-rc1
aa589a1 audit: remove superfluous new- prefix in AUDIT_LOGIN messages
fixed it between 3.14 and 3.15-rc1
So it is fine in 3.15.
2) Userspace silently throws records which are 'malformed'
away, instead
of just printing them...
So according to Linus, we (I) violated the "thou shalt not break
userspace" golden rule with the second patch.
But it was already broken according to Steve which is why the first
patch was submitted.
ausearch -m LOGIN should be able to display these things...
Agreed.
One lesson here? Let's get a minimum useful subset of
http://people.redhat.com/sgrubb/audit/audit-parse.txt into
linux-2.6/Documentation/ tree to try to avoid this issue in the future.
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
10:04 a.m.
On Tuesday, June 17, 2014 10:55:42 AM Richard Guy Briggs wrote:
> This feel like 2 clear bugs.
>
> 1) The kernel records for LOGIN are 'malformed' in 3.14.
Yes. That's why it got fixed for 3.15.
5ee9a75 audit: fix dangling keywords in audit_log_set_loginuid() output
introduced it between 3.13 and 3.14-rc1
aa589a1 audit: remove superfluous new- prefix in AUDIT_LOGIN messages
fixed it between 3.14 and 3.15-rc1
So it is fine in 3.15.
We need this fixed in current kernels. Its a low risk patch that fixes this
problem for a lot of people.
> 2) Userspace silently throws records which are
'malformed' away, instead
> of just printing them...
So according to Linus, we (I) violated the "thou shalt not break
userspace" golden rule with the second patch.
But it was already broken according to Steve which is why the first
patch was submitted.
> ausearch -m LOGIN should be able to display these things...
Agreed.
One lesson here? Let's get a minimum useful subset of
http://people.redhat.com/sgrubb/audit/audit-parse.txt into
linux-2.6/Documentation/ tree to try to avoid this issue in the future.
I'd like to reformat that before putting it in the linux kernel. It needs to
be written from a generic howto perspective and not a library design
perspective. Although that document is what has guided audit event design for
about 8 or 9 years.
-Steve
9:56 a.m.
On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
On Tue, 17 Jun 2014 16:09:32 +0200
Laurent Bigonville <bigon(a)debian.org> wrote:
> Le Tue, 17 Jun 2014 09:29:21 -0400,
>
> Steve Grubb <sgrubb(a)redhat.com> a écrit :
> > On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
> [...]
>
> > > I'd call this a pretty clear userspace bug where it just
> > > completely drops records, even if it can't parse them...
> >
> > That theory can be tested by using:
> >
> > ausearch --start this-week --debug > /dev/null
> >
> > Anything that gets tossed out will be reported to stderr.
>
> I'm getting indeed quite a lot of skipped event:
>
> Malformed event skipped, rc=7. type=LOGIN
> msg=audit(1402934401.462:1626): pid=1719 uid=0 old-auid=4294967295
> new-auid=0 old-ses=4294967295 new-ses=121 res=1
This feel like 2 clear bugs.
1) The kernel records for LOGIN are 'malformed' in 3.14.
Was the patch sent to stable? If not, could it be?
2) Userspace silently throws records which are 'malformed'
away, instead
of just printing them...
ausearch -m LOGIN should be able to display these things...
The problem is that all of the utilities are expecting fields with certain
names in a certain order. Moving them around or changing them breaks things.
When we add work-arounds, it causes the utilities to run slower because it
tries one method and then another. When you run test cases that parse 100 Gb
of logs, you'll see the effects of the work-arounds because the search takes
minutes rather than seconds. The utilities are tuned for the massive logs use
case.
The particular code in question, ausearch-parse.c is used by both aureport and
ausearch. It does not have a concept of completing search criteria and just
dumping the record out. There might be something that can be done here, but
lots a changes risks breaking things in subtle ways.
-Steve
10:15 a.m.
On 14/06/17, Steve Grubb wrote:
On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
> On Tue, 17 Jun 2014 16:09:32 +0200
>
> Laurent Bigonville <bigon(a)debian.org> wrote:
> > Le Tue, 17 Jun 2014 09:29:21 -0400,
> >
> > Steve Grubb <sgrubb(a)redhat.com> a écrit :
> > > On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
> > [...]
> >
> > > > I'd call this a pretty clear userspace bug where it just
> > > > completely drops records, even if it can't parse them...
> > >
> > > That theory can be tested by using:
> > >
> > > ausearch --start this-week --debug > /dev/null
> > >
> > > Anything that gets tossed out will be reported to stderr.
> >
> > I'm getting indeed quite a lot of skipped event:
> >
> > Malformed event skipped, rc=7. type=LOGIN
> > msg=audit(1402934401.462:1626): pid=1719 uid=0 old-auid=4294967295
> > new-auid=0 old-ses=4294967295 new-ses=121 res=1
>
> This feel like 2 clear bugs.
>
> 1) The kernel records for LOGIN are 'malformed' in 3.14.
Was the patch sent to stable? If not, could it be?
To the best of my knowledge, no. This sounds reasonable.
> 2) Userspace silently throws records which are
'malformed' away, instead
> of just printing them...
>
> ausearch -m LOGIN should be able to display these things...
The problem is that all of the utilities are expecting fields with certain
names in a certain order. Moving them around or changing them breaks things.
When we add work-arounds, it causes the utilities to run slower because it
tries one method and then another. When you run test cases that parse 100 Gb
of logs, you'll see the effects of the work-arounds because the search takes
minutes rather than seconds. The utilities are tuned for the massive logs use
case.
The particular code in question, ausearch-parse.c is used by both aureport and
ausearch. It does not have a concept of completing search criteria and just
dumping the record out. There might be something that can be done here, but
lots a changes risks breaking things in subtle ways.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
10:26 a.m.
On Tue, 17 Jun 2014 10:56:24 -0400
Steve Grubb <sgrubb(a)redhat.com> wrote:
On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
> On Tue, 17 Jun 2014 16:09:32 +0200
> 2) Userspace silently throws records which are
'malformed' away,
> instead of just printing them...
>
> ausearch -m LOGIN should be able to display these things...
It does not have a concept of completing
search criteria and just dumping the record out. There might be
something that can be done here, but lots a changes risks breaking
things in subtle ways.
I understand, but I can't imagine any customer that would want these
records silently thrown away. When grep is a more reliable tool, we're in
trouble :)
11:30 a.m.
On Tuesday, June 17, 2014 11:26:01 AM Eric Paris wrote:
On Tue, 17 Jun 2014 10:56:24 -0400
Steve Grubb <sgrubb(a)redhat.com> wrote:
> On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
> > On Tue, 17 Jun 2014 16:09:32 +0200
> >
> > 2) Userspace silently throws records which are 'malformed' away,
> > instead of just printing them...
> >
> > ausearch -m LOGIN should be able to display these things...
>
> It does not have a concept of completing
> search criteria and just dumping the record out. There might be
> something that can be done here, but lots a changes risks breaking
> things in subtle ways.
I understand, but I can't imagine any customer that would want these
records silently thrown away. When grep is a more reliable tool, we're in
trouble :)
Grep is not trying to make sense out of the audit trail. :-) I checked in a
change that helps some, but it only fixes ausearch when loginuid is not
specified.
https://fedorahosted.org/audit/changeset/957
-Steve
3840
days inactive
3853
days old
linux-audit@lists.linux-audit.osci.io
17 comments
4 participants
participants (4)
-
Eric Paris -
Laurent Bigonville -
Richard Guy Briggs -
Steve Grubb