ausearch question

ausearch question

[LC Bruzenak]

I was wondering what a "-ts now" would return from my audit data.
I thought maybe it would be similar to a "tail" of the data, but that's
not what I got.

Is this what you'd expect?:

[root@hugo ~]# date ; ausearch -i -ts now --just-one
Thu May  1 14:05:10 EDT 2008
----
type=DAEMON_START msg=audit(05/01/2008 09:14:40.029:3602) : auditd
start, ver=1.7.2 format=raw kernel=2.6.25-1.fc9.x86_64 auid=unset
pid=2003 res=success 


Most of the relevant data is in the record, however:
[root@hugo ~]# uname -a
Linux hugo 2.6.25-1.fc9.x86_64 #1 SMP Thu Apr 17 01:11:31 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux

[root@hugo ~]# rpm -qa | grep audit
audit-libs-1.7.2-6.fc9.i386
audit-1.7.2-6.fc9.x86_64
audit-libs-python-1.7.2-6.fc9.x86_64
audit-libs-devel-1.7.2-6.fc9.x86_64
audit-libs-devel-1.7.2-6.fc9.i386
audit-libs-1.7.2-6.fc9.x86_64

Thx,
LCB.
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: ausearch question

[Steve Grubb]

On Thursday 01 May 2008 14:11:19 LC Bruzenak wrote:
> I was wondering what a "-ts now" would return from my audit data.

What's in the audit logs starting now. aureport uses the exact same code as 
ausearch for time operations, so its more informative to use it to see what 
time is actually resolved from these keywords. I get:

Summary Report
======================
Range of time in logs: 04/25/2008 09:31:10.388 - 05/02/2008 09:57:20.859
Selected time for report: 05/02/2008 00:00:00 - 05/02/2008 09:57:20.859

Which is clearly wrong. This looks like its resolving to today instead of now. 
I expect ausearch --start now to return nothing unless the system is busy 
doing a lot of logging and you get records between the time it gets system 
time until the time it opens the last log file for reading.

> I thought maybe it would be similar to a "tail" of the data, but that's
> not what I got.

No, tail is not easy to do. Patches are welcome if anyone wants to do it. But 
you can do:

tail -f /var/log/audit/audit.log | ausearch -i

if you wanted that.

-Steve

ausearch question

[Burn Alting]

All,

I note when interpreting raw audit with the ausearch --interpret option,
the code in src/ausearch-report.c:output_interpreted_node(), when
parsing key value pairs which are not enclosed in double or single
quotes, looks for embedded comma's in the value part and, if found,
effectively terminates the value at the comma. This in effect, makes the
data after the comma the start of the next key (if any). There are some
exceptions in the code (audit_type == AUDIT_VIRT_MACHINE_ID,
AUDIT_OBJ_PID, AUDIT_PATH and AUDIT_IPC).

What sort of input is this addressing?

Are there examples?

Thanks in advance

Burn

Re: ausearch question

[Steve Grubb]

On Monday, April 07, 2014 04:29:34 PM Burn Alting wrote:
> All,
> 
> I note when interpreting raw audit with the ausearch --interpret option,
> the code in src/ausearch-report.c:output_interpreted_node(), when
> parsing key value pairs which are not enclosed in double or single
> quotes, looks for embedded comma's in the value part and, if found,
> effectively terminates the value at the comma. This in effect, makes the
> data after the comma the start of the next key (if any). There are some
> exceptions in the code (audit_type == AUDIT_VIRT_MACHINE_ID,
> AUDIT_OBJ_PID, AUDIT_PATH and AUDIT_IPC).

I presume we are talking about this area of code:
https://fedorahosted.org/audit/browser/trunk/src/ausearch-report.c#L276

> What sort of input is this addressing?

The audit system has migrated its events slowly over time. The current code 
base can read/search/report/interpret audit events all the way back to about 
the 2004 time frame. So, sometimes you find things that are left over from long 
ago. But you might need this legacy support if the tools are on an aggregating 
server.


> Are there examples?

type=USER_ACCT msg=audit(1223987805.696:8): user pid=4885 uid=0 
auid=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='PAM: 
accounting acct="sgrubb" : exe="/usr/sbin/gdm-binary" (hostname=?, addr=?, 
terminal=:0 res=success)'

Up until around 2010, all user space originating events had commas between the 
last 4 fields which also including being inside parenthesis. This was later 
decided to be a waste of bytes and slowed down parsing to handle the comma for 
matching/translating purposes. Current events do not have this.

If you see any current events that are mishandled by this legacy code, let me 
know and I'll see how we can fix it.

-Steve

Re: ausearch question

[Burn Alting]

On Mon, 2014-04-07 at 09:59 -0400, Steve Grubb wrote:
> On Monday, April 07, 2014 04:29:34 PM Burn Alting wrote:
> > All,
> > 
> > I note when interpreting raw audit with the ausearch --interpret option,
> > the code in src/ausearch-report.c:output_interpreted_node(), when
> > parsing key value pairs which are not enclosed in double or single
> > quotes, looks for embedded comma's in the value part and, if found,
> > effectively terminates the value at the comma. This in effect, makes the
> > data after the comma the start of the next key (if any). There are some
> > exceptions in the code (audit_type == AUDIT_VIRT_MACHINE_ID,
> > AUDIT_OBJ_PID, AUDIT_PATH and AUDIT_IPC).
> 
> I presume we are talking about this area of code:
> https://fedorahosted.org/audit/browser/trunk/src/ausearch-report.c#L276

Yep.

> 
> > What sort of input is this addressing?
> 
> The audit system has migrated its events slowly over time. The current code 
> base can read/search/report/interpret audit events all the way back to about 
> the 2004 time frame. So, sometimes you find things that are left over from long 
> ago. But you might need this legacy support if the tools are on an aggregating 
> server.

Understood.

> 
> 
> > Are there examples?
> 
> type=USER_ACCT msg=audit(1223987805.696:8): user pid=4885 uid=0 
> auid=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='PAM: 
> accounting acct="sgrubb" : exe="/usr/sbin/gdm-binary" (hostname=?, addr=?, 
> terminal=:0 res=success)'
> 
> Up until around 2010, all user space originating events had commas between the 
> last 4 fields which also including being inside parenthesis. This was later 
> decided to be a waste of bytes and slowed down parsing to handle the comma for 
> matching/translating purposes. Current events do not have this.

Which is exactly the information I was after.
> 
> If you see any current events that are mishandled by this legacy code, let me 
> know and I'll see how we can fix it.

A very, very quick glance through the current kernel and Linux-PAM code
showed, happily, nothing containing the offending format.

> 
> -Steve
> 

Thanks.

Burn