Proposed additions to ausearch

Proposed additions to ausearch

[Burn Alting]

I want to add a number of features to ausearch and would like the list
to make comment on my proposals before implementing same.

#1
Have ausearch only output whole events (all supplemental records of an
event must be present in the audit.log files to be output) and maintain
state to know the last whole event displayed.

The use case is for when one periodically processes the audit log files
and the last log file opened does not necessarily hold whole events for
the last few events in the file.

One could possibly achieve this using the --start/--end arguments to
ausearch but it would be challenging to work out the appropriate
start/end times on a high log throughput system.

My plan is to maintain state recording the last whole event displayed
along with details of the file it resided in (eg inode, etc).

#2
Add a 'parser friendly' option to ausearch's -i output such that it is
more friendly for parsing. As we know, the -i argument causes output in
the form of
  - a "header" comprising
    - the node if present as a key value pair
    - the event type as a key value pair
    - the message date/time and serial
  - a colon
  - a series of key value pairs

The new option would have output that
  - surrounds all values with double quotes
  - escape embedded double quote and backslash characters in the value
with the backslash character '\'
  - translate embedded newlines or carriage returns into '\n' and '\r'
respectively
  - translate all non-printing characters into escaped octal values or
some other recommended text based format.

#3
Add an option to include the original value as well as the interpreted
value when interpretation (-i) is requested. This would be for specified
keys or, key types.

One use case would be for user or group names to include the original
uid/gids. This is to aid de-conflicting inadvertent user or group
attribution across an enterprise environment.

The option would have arguments that identify what key values will have
both original and interpreted values.

Regards
Burn Alting

Re: Proposed additions to ausearch

[Burn Alting]

All,
 
I have completed all the items listed below against ausearch. That is
 
        - it can now checkpoint itself, in that, successive invocations
        will only display new events
        
        - a new option will print out more parser friendly output for
        interpreted mode
        
        - a new option will also print out some values both in it's
        original as well as interpreted form
 
Whilst doing this, I fixed some very minor bugs or annoyances.

        - when ausearch processes events, incomplete events are
        considered as complete (and hence printed) when ausearch
        encounters an EOF on input. Now, ausearch will carry over
        incomplete events, providing the opportunity to complete them,
        unless it's the last file ausearch is processing
        
        - ausearch -i now identifies ANY quoted values on input and
        considers these values of type T_ESCAPED and hence will be
        processed via the print_escaped() routine. It was noticed keys
        such as ocomm, dev and op could have quoted values as per
                ... opid=717 oauid=42 ouid=0 oses=1
                obj=system_u:system_r:xdm_t:s0-s0:c0.c1023
                ocomm="gdm-session-wor"
                ... avc:  denied  { read } for  pid=21340
                comm="unix_chkpwd" name="libaudit.so.1.0.0" dev="dm-1"
                ino=394483
                scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023
                tcontext=system_u:object_r:default_t:s0 tclass=file
                ... auid=4294967295 ses=4294967295
                subj=system_u:system_r:init_t:s0 op="add rule"
                key="time-change" list=4 res=1
        The change identifies ANY value with double quotes around the
        value and offers their interpretation via the print_escaped()
        routine. The alternative is to add the above three keys to the
        typetab[] array.
        
        - when processing flag values in interpretive mode, a trailing
        space was always printed whether the flags key value pair was
        the last pair on the event record or not.
 
Should I submit this as one patch or multiple? I have a single patch
file (including mods to ausearch.8) but if required, I may be able to
present each new feature as it's own patch and/or the bugs as a group.

The patch(es) would be against audit-2.3.

Regards
Burn

On Sat, 2013-04-20 at 22:22 +1000, Burn Alting wrote:
> I want to add a number of features to ausearch and would like the list
> to make comment on my proposals before implementing same.
> 
> #1
> Have ausearch only output whole events (all supplemental records of an
> event must be present in the audit.log files to be output) and maintain
> state to know the last whole event displayed.
> 
> The use case is for when one periodically processes the audit log files
> and the last log file opened does not necessarily hold whole events for
> the last few events in the file.
> 
> One could possibly achieve this using the --start/--end arguments to
> ausearch but it would be challenging to work out the appropriate
> start/end times on a high log throughput system.
> 
> My plan is to maintain state recording the last whole event displayed
> along with details of the file it resided in (eg inode, etc).
> 
> #2
> Add a 'parser friendly' option to ausearch's -i output such that it is
> more friendly for parsing. As we know, the -i argument causes output in
> the form of
>   - a "header" comprising
>     - the node if present as a key value pair
>     - the event type as a key value pair
>     - the message date/time and serial
>   - a colon
>   - a series of key value pairs
> 
> The new option would have output that
>   - surrounds all values with double quotes
>   - escape embedded double quote and backslash characters in the value
> with the backslash character '\'
>   - translate embedded newlines or carriage returns into '\n' and '\r'
> respectively
>   - translate all non-printing characters into escaped octal values or
> some other recommended text based format.
> 
> #3
> Add an option to include the original value as well as the interpreted
> value when interpretation (-i) is requested. This would be for specified
> keys or, key types.
> 
> One use case would be for user or group names to include the original
> uid/gids. This is to aid de-conflicting inadvertent user or group
> attribution across an enterprise environment.
> 
> The option would have arguments that identify what key values will have
> both original and interpreted values.
> 
> Regards
> Burn Alting
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Proposed additions to ausearch

[Steve Grubb]

Hello,

On Sunday, May 05, 2013 06:21:57 PM Burn Alting wrote:
> I have completed all the items listed below against ausearch. That is
> 
>         - it can now checkpoint itself, in that, successive invocations
>         will only display new events

Go ahead and send this one. It shouldn't disturb other work.

>         - a new option will print out more parser friendly output for
>         interpreted mode

I am in the midst of coalescing the interpreters into one. I know this sounds 
crazy, but ausearch and auparse both had independent copies of nearly the same 
material. The problem was they both keep data formatted completely different 
and that made combining them a challenge. I think auparse has a faster lookup 
algorithm but it allocates memory for the translation. So, I hope they cancel 
each other out.

My point in mentioning this is that I am probably in the middle of changing 
code you hooked into. The work is checked in but still in progress. The first 
step was to create a common API for 3 functions used in translating fields. 
(This is checked in.) The next step is to link ausearch against auparse with 
the ausearch functions commented out. The final step is to remove all the 
unneeded code from ausearch. (I should be doing this today.)


>         - a new option will also print out some values both in it's
>         original as well as interpreted form

This is something I'm still pondering what the best approach is. It could be 
possible to generate an audit uid/gid mapping when the audit daemon starts and 
add that as a record. Ausearch can use this record as needed. Then any user 
add/delete events could be added to a table for display. The problem comes 
when you have really large installs in which case it might be best to have a 
static uid mapping for all users and they have to always use the same uid no 
matter which system they log into. Of course this gets tricky for system 
services which can have a different uid from machine to machine.

Another way of doing this would be to add a translation record to each event. 
This increases the storage size, though.


> Whilst doing this, I fixed some very minor bugs or annoyances.
> 
>         - when ausearch processes events, incomplete events are
>         considered as complete (and hence printed) when ausearch
>         encounters an EOF on input. Now, ausearch will carry over
>         incomplete events, providing the opportunity to complete them,
>         unless it's the last file ausearch is processing

Go ahead and send this.


>         - ausearch -i now identifies ANY quoted values on input and
>         considers these values of type T_ESCAPED and hence will be
>         processed via the print_escaped() routine. It was noticed keys
>         such as ocomm, dev and op could have quoted values as per
>                 ... opid=717 oauid=42 ouid=0 oses=1
>                 obj=system_u:system_r:xdm_t:s0-s0:c0.c1023
>                 ocomm="gdm-session-wor"

I'll fix this...thought I had them all.


>                 ... avc:  denied  { read } for  pid=21340
>                 comm="unix_chkpwd" name="libaudit.so.1.0.0" dev="dm-1"
>                 ino=394483
>                 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023
>                 tcontext=system_u:object_r:default_t:s0 tclass=file

Yes, I saw this one yesterday. I think the root cause of this is the AVC text 
is malformed. dev is already used and its a device number, not a name. This 
field's name should change since its recording the wrong value for that field's 
name.

>                 ... auid=4294967295 ses=4294967295
>                 subj=system_u:system_r:init_t:s0 op="add rule"
>                 key="time-change" list=4 res=1

This is malformed because the kernel is doing it wrong. Its code must be fixed. 
Additionally, I am certain there are other cases of this.


>         The change identifies ANY value with double quotes around the
>         value and offers their interpretation via the print_escaped()
>         routine. The alternative is to add the above three keys to the
>         typetab[] array.

Sometimes this catches problems on the event logging side.
 
>         - when processing flag values in interpretive mode, a trailing
>         space was always printed whether the flags key value pair was
>         the last pair on the event record or not.

Not sure about this one...but it should be checked after the ausearch/parse 
redundancy is fixed.


> Should I submit this as one patch or multiple? I have a single patch
> file (including mods to ausearch.8) but if required, I may be able to
> present each new feature as it's own patch and/or the bugs as a group.
> 
> The patch(es) would be against audit-2.3.

Its best to submit these one by one. It probably would have been best to send 
these as you completed each item so they could be reviewed/discussed/merged at 
leisure.

Thanks,
-Steve

Re: Proposed additions to ausearch

[Steve Grubb]

On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> >         - a new option will print out more parser friendly output for
> >         interpreted mode
> 
> I am in the midst of coalescing the interpreters into one. I know this
> sounds  crazy, but ausearch and auparse both had independent copies of
> nearly the same material. The problem was they both keep data formatted
> completely different and that made combining them a challenge. I think
> auparse has a faster lookup algorithm but it allocates memory for the
> translation. So, I hope they cancel each other out.
> 
> My point in mentioning this is that I am probably in the middle of changing 
> code you hooked into. The work is checked in but still in progress. The
> first step was to create a common API for 3 functions used in translating
> fields. (This is checked in.) The next step is to link ausearch against
> auparse with the ausearch functions commented out. The final step is to
> remove all the unneeded code from ausearch. (I should be doing this today.)

All changes are checked into svn for this interpreter switch over. So far my 
testing shows that although ausearch malloc/frees about 6 times as much as it 
used to, the lookup algorithms in auparse are superior and we actually have 
about a 20% speed improvement in the outputting of interpreted results. 
Searching is not any faster. 

At this point, the code should be stable in this area if you want to retest 
and start sending patches.

Thanks,
-Steve

Re: Proposed additions to ausearch

[Burn Alting]

Thanks Steve,

I will check it out and re-fit patches over the next few days and submit
individual patches for review.

Rgds

Burn


On Mon, 2013-05-06 at 18:04 -0400, Steve Grubb wrote:
> On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> > >         - a new option will print out more parser friendly output for
> > >         interpreted mode
> > 
> > I am in the midst of coalescing the interpreters into one. I know this
> > sounds  crazy, but ausearch and auparse both had independent copies of
> > nearly the same material. The problem was they both keep data formatted
> > completely different and that made combining them a challenge. I think
> > auparse has a faster lookup algorithm but it allocates memory for the
> > translation. So, I hope they cancel each other out.
> > 
> > My point in mentioning this is that I am probably in the middle of changing 
> > code you hooked into. The work is checked in but still in progress. The
> > first step was to create a common API for 3 functions used in translating
> > fields. (This is checked in.) The next step is to link ausearch against
> > auparse with the ausearch functions commented out. The final step is to
> > remove all the unneeded code from ausearch. (I should be doing this today.)
> 
> All changes are checked into svn for this interpreter switch over. So far my 
> testing shows that although ausearch malloc/frees about 6 times as much as it 
> used to, the lookup algorithms in auparse are superior and we actually have 
> about a 20% speed improvement in the outputting of interpreted results. 
> Searching is not any faster. 
> 
> At this point, the code should be stable in this area if you want to retest 
> and start sending patches.
> 
> Thanks,
> -Steve

Re: Proposed additions to ausearch

[Burn Alting]

Steve,

Before I send my patches out, I noticed in some testing of the svn code,
that some interpretation of the a2 and a3 keys has resulted in null
output if the raw data was 0. For example
raw:
        node=swtf5.swtf.dyndns.org type=SYSCALL
        msg=audit(1367146452.398:27817): arch=c000003e syscall=45
        success=no exit=-11 a0=6 a1=2546a04 a2=1000 a3=0 items=0
        ppid=798 pid=1227 auid=42 uid=42 gid=42 euid=42 suid=42 fsuid=42
        egid=42 sgid=42 fsgid=42 ses=1 tty=(none) comm="gnome-shell"
        exe=2F7573722F62696E2F676E6F6D652D7368656C6C202864656C6574656429
        subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key="all"
2.3 output
        < node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
        20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
        exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
        a2=0x1000 a3=0x0 items=0 ppid=798 pid=1227 auid=gdm uid=gdm
        gid=gdm euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm
        ses=1 tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell
        (deleted) subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 
        ---
svn
        > node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
        20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
        exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
        a2=0x1000 a3= items=0 ppid=798 pid=1227 auid=gdm uid=gdm gid=gdm
        euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm ses=1
        tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell (deleted)
        subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 

This appears to occur for recvfrom, sendmsg, sendto. I've yet to look
for other syscalls that it effects.

Rgds

On Tue, 2013-05-07 at 19:29 +1000, Burn Alting wrote:
> Thanks Steve,
> 
> I will check it out and re-fit patches over the next few days and submit
> individual patches for review.
> 
> Rgds
> 
> Burn
> 
> 
> On Mon, 2013-05-06 at 18:04 -0400, Steve Grubb wrote:
> > On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> > > >         - a new option will print out more parser friendly output for
> > > >         interpreted mode
> > > 
> > > I am in the midst of coalescing the interpreters into one. I know this
> > > sounds  crazy, but ausearch and auparse both had independent copies of
> > > nearly the same material. The problem was they both keep data formatted
> > > completely different and that made combining them a challenge. I think
> > > auparse has a faster lookup algorithm but it allocates memory for the
> > > translation. So, I hope they cancel each other out.
> > > 
> > > My point in mentioning this is that I am probably in the middle of changing 
> > > code you hooked into. The work is checked in but still in progress. The
> > > first step was to create a common API for 3 functions used in translating
> > > fields. (This is checked in.) The next step is to link ausearch against
> > > auparse with the ausearch functions commented out. The final step is to
> > > remove all the unneeded code from ausearch. (I should be doing this today.)
> > 
> > All changes are checked into svn for this interpreter switch over. So far my 
> > testing shows that although ausearch malloc/frees about 6 times as much as it 
> > used to, the lookup algorithms in auparse are superior and we actually have 
> > about a 20% speed improvement in the outputting of interpreted results. 
> > Searching is not any faster. 
> > 
> > At this point, the code should be stable in this area if you want to retest 
> > and start sending patches.
> > 
> > Thanks,
> > -Steve
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Proposed additions to ausearch

[Burn Alting]

[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]

And the trivial patch to fix is attached.

Also in the patch is a minor fix to display the clone flag value of 0 as
0x0 for consistency.

On Sat, 2013-05-11 at 10:42 +1000, Burn Alting wrote:
> Steve,
> 
> Before I send my patches out, I noticed in some testing of the svn code,
> that some interpretation of the a2 and a3 keys has resulted in null
> output if the raw data was 0. For example
> raw:
>         node=swtf5.swtf.dyndns.org type=SYSCALL
>         msg=audit(1367146452.398:27817): arch=c000003e syscall=45
>         success=no exit=-11 a0=6 a1=2546a04 a2=1000 a3=0 items=0
>         ppid=798 pid=1227 auid=42 uid=42 gid=42 euid=42 suid=42 fsuid=42
>         egid=42 sgid=42 fsgid=42 ses=1 tty=(none) comm="gnome-shell"
>         exe=2F7573722F62696E2F676E6F6D652D7368656C6C202864656C6574656429
>         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key="all"
> 2.3 output
>         < node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
>         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
>         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
>         a2=0x1000 a3=0x0 items=0 ppid=798 pid=1227 auid=gdm uid=gdm
>         gid=gdm euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm
>         ses=1 tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell
>         (deleted) subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 
>         ---
> svn
>         > node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
>         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
>         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
>         a2=0x1000 a3= items=0 ppid=798 pid=1227 auid=gdm uid=gdm gid=gdm
>         euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm ses=1
>         tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell (deleted)
>         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 
> 
> This appears to occur for recvfrom, sendmsg, sendto. I've yet to look
> for other syscalls that it effects.
> 
> Rgds
> 
> On Tue, 2013-05-07 at 19:29 +1000, Burn Alting wrote:
> > Thanks Steve,
> > 
> > I will check it out and re-fit patches over the next few days and submit
> > individual patches for review.
> > 
> > Rgds
> > 
> > Burn
> > 
> > 
> > On Mon, 2013-05-06 at 18:04 -0400, Steve Grubb wrote:
> > > On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> > > > >         - a new option will print out more parser friendly output for
> > > > >         interpreted mode
> > > > 
> > > > I am in the midst of coalescing the interpreters into one. I know this
> > > > sounds  crazy, but ausearch and auparse both had independent copies of
> > > > nearly the same material. The problem was they both keep data formatted
> > > > completely different and that made combining them a challenge. I think
> > > > auparse has a faster lookup algorithm but it allocates memory for the
> > > > translation. So, I hope they cancel each other out.
> > > > 
> > > > My point in mentioning this is that I am probably in the middle of changing 
> > > > code you hooked into. The work is checked in but still in progress. The
> > > > first step was to create a common API for 3 functions used in translating
> > > > fields. (This is checked in.) The next step is to link ausearch against
> > > > auparse with the ausearch functions commented out. The final step is to
> > > > remove all the unneeded code from ausearch. (I should be doing this today.)
> > > 
> > > All changes are checked into svn for this interpreter switch over. So far my 
> > > testing shows that although ausearch malloc/frees about 6 times as much as it 
> > > used to, the lookup algorithms in auparse are superior and we actually have 
> > > about a 20% speed improvement in the outputting of interpreted results. 
> > > Searching is not any faster. 
> > > 
> > > At this point, the code should be stable in this area if you want to retest 
> > > and start sending patches.
> > > 
> > > Thanks,
> > > -Steve
> > 
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


[-- Attachment #2: auparse_interpret_fix1.patch --]
[-- Type: text/x-patch, Size: 599 bytes --]

diff -Npru trunk/auparse/interpret.c trunk_clean/auparse/interpret.c
--- trunk/auparse/interpret.c	2013-05-11 14:49:41.911849479 +1000
+++ trunk_clean/auparse/interpret.c	2013-05-12 09:00:05.140509690 +1000
@@ -970,7 +970,7 @@ static const char *print_clone_flags(con
 	}
 
 	if (buf[0] == 0)
-		snprintf(buf, sizeof(buf), "%d", flags);
+		snprintf(buf, sizeof(buf), "0x%x", flags);
 	return strdup(buf);
 }
 
@@ -1270,6 +1270,8 @@ static const char *print_recv(const char
 			}
                 }
         }
+	if (buf[0] == 0)
+		snprintf(buf, sizeof(buf), "0x%x", flags);
 	return strdup(buf);
 }

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Proposed additions to ausearch

[Burn Alting]

[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]

Hmmm ... lets try that again with the correct and working patch.

Apologies
Burn

On Sun, 2013-05-12 at 09:14 +1000, Burn Alting wrote:
> And the trivial patch to fix is attached.
> 
> Also in the patch is a minor fix to display the clone flag value of 0 as
> 0x0 for consistency.
> 
> On Sat, 2013-05-11 at 10:42 +1000, Burn Alting wrote:
> > Steve,
> > 
> > Before I send my patches out, I noticed in some testing of the svn code,
> > that some interpretation of the a2 and a3 keys has resulted in null
> > output if the raw data was 0. For example
> > raw:
> >         node=swtf5.swtf.dyndns.org type=SYSCALL
> >         msg=audit(1367146452.398:27817): arch=c000003e syscall=45
> >         success=no exit=-11 a0=6 a1=2546a04 a2=1000 a3=0 items=0
> >         ppid=798 pid=1227 auid=42 uid=42 gid=42 euid=42 suid=42 fsuid=42
> >         egid=42 sgid=42 fsgid=42 ses=1 tty=(none) comm="gnome-shell"
> >         exe=2F7573722F62696E2F676E6F6D652D7368656C6C202864656C6574656429
> >         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key="all"
> > 2.3 output
> >         < node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
> >         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
> >         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
> >         a2=0x1000 a3=0x0 items=0 ppid=798 pid=1227 auid=gdm uid=gdm
> >         gid=gdm euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm
> >         ses=1 tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell
> >         (deleted) subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 
> >         ---
> > svn
> >         > node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
> >         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
> >         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
> >         a2=0x1000 a3= items=0 ppid=798 pid=1227 auid=gdm uid=gdm gid=gdm
> >         euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm ses=1
> >         tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell (deleted)
> >         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all 
> > 
> > This appears to occur for recvfrom, sendmsg, sendto. I've yet to look
> > for other syscalls that it effects.
> > 
> > Rgds
> > 
> > On Tue, 2013-05-07 at 19:29 +1000, Burn Alting wrote:
> > > Thanks Steve,
> > > 
> > > I will check it out and re-fit patches over the next few days and submit
> > > individual patches for review.
> > > 
> > > Rgds
> > > 
> > > Burn
> > > 
> > > 
> > > On Mon, 2013-05-06 at 18:04 -0400, Steve Grubb wrote:
> > > > On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> > > > > >         - a new option will print out more parser friendly output for
> > > > > >         interpreted mode
> > > > > 
> > > > > I am in the midst of coalescing the interpreters into one. I know this
> > > > > sounds  crazy, but ausearch and auparse both had independent copies of
> > > > > nearly the same material. The problem was they both keep data formatted
> > > > > completely different and that made combining them a challenge. I think
> > > > > auparse has a faster lookup algorithm but it allocates memory for the
> > > > > translation. So, I hope they cancel each other out.
> > > > > 
> > > > > My point in mentioning this is that I am probably in the middle of changing 
> > > > > code you hooked into. The work is checked in but still in progress. The
> > > > > first step was to create a common API for 3 functions used in translating
> > > > > fields. (This is checked in.) The next step is to link ausearch against
> > > > > auparse with the ausearch functions commented out. The final step is to
> > > > > remove all the unneeded code from ausearch. (I should be doing this today.)
> > > > 
> > > > All changes are checked into svn for this interpreter switch over. So far my 
> > > > testing shows that although ausearch malloc/frees about 6 times as much as it 
> > > > used to, the lookup algorithms in auparse are superior and we actually have 
> > > > about a 20% speed improvement in the outputting of interpreted results. 
> > > > Searching is not any faster. 
> > > > 
> > > > At this point, the code should be stable in this area if you want to retest 
> > > > and start sending patches.
> > > > 
> > > > Thanks,
> > > > -Steve
> > > 
> > > 
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> > 
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


[-- Attachment #2: auparse_interpret_fix1_correct.patch --]
[-- Type: text/x-patch, Size: 601 bytes --]

diff -Npru trunk_0/auparse/interpret.c trunk_clean/auparse/interpret.c
--- trunk_0/auparse/interpret.c	2013-05-11 14:49:41.000000000 +1000
+++ trunk_clean/auparse/interpret.c	2013-05-12 09:21:30.433282199 +1000
@@ -970,7 +970,7 @@ static const char *print_clone_flags(con
 	}
 
 	if (buf[0] == 0)
-		snprintf(buf, sizeof(buf), "%d", flags);
+		snprintf(buf, sizeof(buf), "0x%x", flags);
 	return strdup(buf);
 }
 
@@ -1270,6 +1270,8 @@ static const char *print_recv(const char
 			}
                 }
         }
+	if (buf[0] == 0)
+		snprintf(buf, sizeof(buf), "0x%x", rec);
 	return strdup(buf);
 }

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Proposed additions to ausearch

[Steve Grubb]

On Sunday, May 12, 2013 09:30:48 AM Burn Alting wrote:
> Hmmm ... lets try that again with the correct and working patch.

Applied with one change. I also looked for more instances of the same coding 
pattern and fixed several more. Thanks for reporting this.

-Steve


> On Sun, 2013-05-12 at 09:14 +1000, Burn Alting wrote:
> > And the trivial patch to fix is attached.
> > 
> > Also in the patch is a minor fix to display the clone flag value of 0 as
> > 0x0 for consistency.
> > 
> > On Sat, 2013-05-11 at 10:42 +1000, Burn Alting wrote:
> > > Steve,
> > > 
> > > Before I send my patches out, I noticed in some testing of the svn code,
> > > that some interpretation of the a2 and a3 keys has resulted in null
> > > output if the raw data was 0. For example
> > > 
> > > raw:
> > >         node=swtf5.swtf.dyndns.org type=SYSCALL
> > >         msg=audit(1367146452.398:27817): arch=c000003e syscall=45
> > >         success=no exit=-11 a0=6 a1=2546a04 a2=1000 a3=0 items=0
> > >         ppid=798 pid=1227 auid=42 uid=42 gid=42 euid=42 suid=42 fsuid=42
> > >         egid=42 sgid=42 fsgid=42 ses=1 tty=(none) comm="gnome-shell"
> > >         exe=2F7573722F62696E2F676E6F6D652D7368656C6C202864656C6574656429
> > >         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key="all"
> > > 
> > > 2.3 output
> > > 
> > >         < node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
> > >         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
> > >         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
> > >         a2=0x1000 a3=0x0 items=0 ppid=798 pid=1227 auid=gdm uid=gdm
> > >         gid=gdm euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm
> > >         ses=1 tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell
> > >         (deleted) subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all
> > >         ---
> > > 
> > > svn
> > > 
> > >         > node=swtf5.swtf.dyndns.org type=SYSCALL msg=audit(04/28/2013
> > >         
> > >         20:54:12.398:27817) : arch=x86_64 syscall=recvfrom success=no
> > >         exit=-11(Resource temporarily unavailable) a0=0x6 a1=0x2546a04
> > >         a2=0x1000 a3= items=0 ppid=798 pid=1227 auid=gdm uid=gdm gid=gdm
> > >         euid=gdm suid=gdm fsuid=gdm egid=gdm sgid=gdm fsgid=gdm ses=1
> > >         tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell (deleted)
> > >         subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=all
> > > 
> > > This appears to occur for recvfrom, sendmsg, sendto. I've yet to look
> > > for other syscalls that it effects.
> > > 
> > > Rgds
> > > 
> > > On Tue, 2013-05-07 at 19:29 +1000, Burn Alting wrote:
> > > > Thanks Steve,
> > > > 
> > > > I will check it out and re-fit patches over the next few days and
> > > > submit
> > > > individual patches for review.
> > > > 
> > > > Rgds
> > > > 
> > > > Burn
> > > > 
> > > > On Mon, 2013-05-06 at 18:04 -0400, Steve Grubb wrote:
> > > > > On Monday, May 06, 2013 09:53:40 AM Steve Grubb wrote:
> > > > > > >         - a new option will print out more parser friendly
> > > > > > >         output for
> > > > > > >         interpreted mode
> > > > > > 
> > > > > > I am in the midst of coalescing the interpreters into one. I know
> > > > > > this
> > > > > > sounds  crazy, but ausearch and auparse both had independent
> > > > > > copies of
> > > > > > nearly the same material. The problem was they both keep data
> > > > > > formatted
> > > > > > completely different and that made combining them a challenge. I
> > > > > > think
> > > > > > auparse has a faster lookup algorithm but it allocates memory for
> > > > > > the
> > > > > > translation. So, I hope they cancel each other out.
> > > > > > 
> > > > > > My point in mentioning this is that I am probably in the middle of
> > > > > > changing
> > > > > > code you hooked into. The work is checked in but still in
> > > > > > progress. The
> > > > > > first step was to create a common API for 3 functions used in
> > > > > > translating
> > > > > > fields. (This is checked in.) The next step is to link ausearch
> > > > > > against
> > > > > > auparse with the ausearch functions commented out. The final step
> > > > > > is to
> > > > > > remove all the unneeded code from ausearch. (I should be doing
> > > > > > this today.)
> > > > > 
> > > > > All changes are checked into svn for this interpreter switch over.
> > > > > So far my testing shows that although ausearch malloc/frees about 6
> > > > > times as much as it used to, the lookup algorithms in auparse are
> > > > > superior and we actually have about a 20% speed improvement in the
> > > > > outputting of interpreted results. Searching is not any faster.
> > > > > 
> > > > > At this point, the code should be stable in this area if you want to
> > > > > retest
> > > > > and start sending patches.
> > > > > 
> > > > > Thanks,
> > > > > -Steve
> > > > 
> > > > --
> > > > Linux-audit mailing list
> > > > Linux-audit@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > 
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit