6:30 p.m.
Hello,
the attached patch modifies auparse not to handle timestamp 0.x
specially by using out-of-band information (parse_state == EVENT_EMPTY)
instead of assuming (au->le.e.sec == 0) has a special meaning. As far
as I can see, this the two conditions are equivalent if no event has a
timestamp 0.x.
The patch also decreases the assumed minimal length of a timestamp.
I have tested this only minimally - I have checked that (make check)
succeeds, and that audit-viewer doesn't crash on startup.
This patch fixes handling of the following Lenny's audit record:
node=hugo type=AVC msg=audit(0.000:6760): avc: denied { recvfrom }
for pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1
dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
I'm curious how this audit record could have been created (notabile is
that the previous record has a sequence ID 6758 and a reasonable
timestamp). Lenny, Steve, any ideas?
Thank you,
Mirek
7:38 p.m.
On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
Hello,
the attached patch modifies auparse not to handle timestamp 0.x
specially by using out-of-band information (parse_state == EVENT_EMPTY)
instead of assuming (au->le.e.sec == 0) has a special meaning. As far
as I can see, this the two conditions are equivalent if no event has a
timestamp 0.x.
The patch also decreases the assumed minimal length of a timestamp.
I have tested this only minimally - I have checked that (make check)
succeeds, and that audit-viewer doesn't crash on startup.
This patch fixes handling of the following Lenny's audit record:
> node=hugo type=AVC msg=audit(0.000:6760): avc: denied { recvfrom }
> for pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1
> dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
> tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
I'm curious how this audit record could have been created (notabile is
that the previous record has a sequence ID 6758 and a reasonable
timestamp). Lenny, Steve, any ideas?
Thank you,
Mirek
I assume the timestamp is punched in the kernel audit code.
I decided to go rule out aggregation error and went looking on the
originating machine. I found a couple more:
[root@hugo ~]# grep "(0.000:" /var/log/audit/audit.log*
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:6760): avc: denied
{ recvfrom } for pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1
dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:381): avc: denied {
read } for pid=2594 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482
scontext=system_u:system_r:kernel_t:s15:c0.c1023
tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:5135): avc: denied
{ recvfrom } for pid=2595 comm="lockd" saddr=127.0.0.1 src=701 daddr=127.0.0.1
dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
/var/log/audit/audit.log.12:node=local-hugo type=AVC msg=audit(0.000:388): avc: denied {
read } for pid=2593 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482
scontext=system_u:system_r:kernel_t:s15:c0.c1023
tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir
/var/log/audit/audit.log.13:node=local-hugo type=AVC msg=audit(0.000:380): avc: denied {
read } for pid=2588 comm="nfsd4" name="v4recovery" dev=dm-0 ino=34482
scontext=system_u:system_r:kernel_t:s15:c0.c1023
tcontext=system_u:object_r:var_lib_nfs_t:s0 tclass=dir
They all appear to be AVCs on denied read/recvfom, maybe there is a
timestamp bug in there?
Let me know if I can supply any data/diagnostics. I'll have to leave the
kernel code to experts for now...
Thx!
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
7:57 p.m.
LC Bruzenak píše v Po 22. 09. 2008 v 19:38 -0500:
On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
> > node=hugo type=AVC msg=audit(0.000:6760): <SNIP> comm="lockd"
>
> I'm curious how this audit record could have been created (notabile is
> that the previous record has a sequence ID 6758 and a reasonable
> timestamp). Lenny, Steve, any ideas?
I found a couple more:
[root@hugo ~]# grep "(0.000:" /var/log/audit/audit.log*
<SNIP> type=AVC msg=audit(0.000:6760): <SNIP> comm="lockd"
<SNIP> type=AVC msg=audit(0.000:381): <SNIP> comm="nfsd4"
I think I can see what's going on. Those are kernel threads; when they
are created, an audit context is created and zeroed. The timestamp is
set on system call entry in ordinary threads, but there is no system
call entry in kernel threads, so the original zero timestamp is used in
all audit records related to kernel threads.
I'm not sure how to fix it, though. Perhaps identify "operation start"
points in kernel threads, and update the timestamps in their audit
contexts at that time?
Mirek
8:04 p.m.
On Tue, 2008-09-23 at 02:57 +0200, Miloslav Trmač wrote:
LC Bruzenak píše v Po 22. 09. 2008 v 19:38 -0500:
> On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
...
I think I can see what's going on. Those are kernel threads; when they
are created, an audit context is created and zeroed. The timestamp is
set on system call entry in ordinary threads, but there is no system
call entry in kernel threads, so the original zero timestamp is used in
all audit records related to kernel threads.
I'm not sure how to fix it, though. Perhaps identify "operation start"
points in kernel threads, and update the timestamps in their audit
contexts at that time?
Mirek
OK; excellent summary!
The bad thing IMO is that ausearch doesn't show these records.
It just drops them (and exits with exit value = 1).
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
10:51 a.m.
On Monday 22 September 2008 20:57:59 Miloslav Trmač wrote:
LC Bruzenak píše v Po 22. 09. 2008 v 19:38 -0500:
> On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
> > > node=hugo type=AVC msg=audit(0.000:6760): <SNIP>
comm="lockd"
> >
> > I'm curious how this audit record could have been created (notabile is
> > that the previous record has a sequence ID 6758 and a reasonable
> > timestamp). Lenny, Steve, any ideas?
>
> I found a couple more:
>
> [root@hugo ~]# grep "(0.000:" /var/log/audit/audit.log*
> <SNIP> type=AVC msg=audit(0.000:6760): <SNIP> comm="lockd"
> <SNIP> type=AVC msg=audit(0.000:381): <SNIP> comm="nfsd4"
I think I can see what's going on. Those are kernel threads; when they
are created, an audit context is created and zeroed. The timestamp is
set on system call entry in ordinary threads, but there is no system
call entry in kernel threads, so the original zero timestamp is used in
all audit records related to kernel threads.
I'm not sure how to fix it, though. Perhaps identify "operation start"
points in kernel threads, and update the timestamps in their audit
contexts at that time?
Eric, Al,
Any ideas how to fix this?
Thanks,
-Steve
2:19 p.m.
On Mon, 2008-09-22 at 23:30 +0000, Miloslav Trmač wrote:
Hello,
the attached patch modifies auparse not to handle timestamp 0.x
specially by using out-of-band information (parse_state == EVENT_EMPTY)
instead of assuming (au->le.e.sec == 0) has a special meaning. As far
as I can see, this the two conditions are equivalent if no event has a
timestamp 0.x.
The patch also decreases the assumed minimal length of a timestamp.
I have tested this only minimally - I have checked that (make check)
succeeds, and that audit-viewer doesn't crash on startup.
This patch fixes handling of the following Lenny's audit record:
> node=hugo type=AVC msg=audit(0.000:6760): avc: denied { recvfrom }
> for pid=2589 comm="lockd" saddr=127.0.0.1 src=687 daddr=127.0.0.1
> dest=111 netif=lo scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
> tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=association
I'm curious how this audit record could have been created (notabile is
that the previous record has a sequence ID 6758 and a reasonable
timestamp). Lenny, Steve, any ideas?
Thank you,
Mirek
Steve, Mirek -
This patch didn't make it into the 1.7.9 code?
I have been running with it since its release.
Even if the kernel was patched I thought this was good.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
9:17 a.m.
New subject: Account Lockouts
9:25 a.m.
New subject: Account Lockouts
On Wednesday 07 January 2009 10:17:54 am Starr-Renee Corbin wrote:
While the account lockout policy is set, I am unable to figure out
the
syntax for the watches to add to audit.rules that will show the account
lockout event. I have to be able to do this for about 150 systems.
pam_tally2 is hardwired to send lockout events to the audit system. Use it
rather than pam_tally. They will be in the audit logs as ANOM_LOGIN_FAILURES
when the limit is reached, as RESP_ACCT_LOCK_TIMED for the actual locking of
the acct, and RESP_ACCT_UNLOCK_TIMED when the acct is unlocked due to time
expiration or admin action.
-Steve
5836
days inactive
5943
days old
linux-audit@lists.linux-audit.osci.io
7 comments
4 participants
participants (4)
-
LC Bruzenak -
Miloslav Trmač -
Starr-Renee Corbin -
Steve Grubb