public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
* auparse, stdin, and AUPARSE_CB_EVENT_READY
@ 2012-03-06  0:23 dump
  2012-03-07 16:50 ` Guillaume Destuynder
  2012-03-07 17:48 ` Steve Grubb
  0 siblings, 2 replies; 4+ messages in thread
From: dump @ 2012-03-06  0:23 UTC (permalink / raw)
  To: linux-audit

Hi,

I made a audispd plugin, which reads from stdin and sends the strings to
auparse_feed() (auditd-2.1.3).


This works fine on the command line.

When called from audispd however, it gives AUPARSE_CB_EVENT_READY for
each single message, instead of after a complete event has been parsed.

So when you have 4 messages for one event:
- each of them appear as a single event when the plugin is started via
audispd.
- a single even for all 4 messages appear when the plugin is started on
the command line (and the log data fed via stdin, like cat test |
audispd-testplugin)

Looking at the write code it looks ok (audisp/audispd.c):

static int write_to_plugin(event_t *e, const char *string, size_t
string_len,
.. (note that i'm using string type so its the string code part)
if (conf->p->format == F_STRING) {
do {
rc = write(conf->p->plug_pipe[1], string, string_len);
} while (rc < 0 && errno == EINTR);
}

Do you know what causes this behavior, and/or how to "fix" it?


Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: auparse, stdin, and AUPARSE_CB_EVENT_READY
  2012-03-06  0:23 auparse, stdin, and AUPARSE_CB_EVENT_READY dump
@ 2012-03-07 16:50 ` Guillaume Destuynder
  2012-03-07 17:19   ` Steve Grubb
  2012-03-07 17:48 ` Steve Grubb
  1 sibling, 1 reply; 4+ messages in thread
From: Guillaume Destuynder @ 2012-03-07 16:50 UTC (permalink / raw)
  To: linux-audit

Below patch "fixes" it. The problem is that if you have a node name
included in the message, and that it's a long hostname, it's just not
copying a long enough string, and it will fail to parse the message
serial. When the serial is incorrect, auparse will fail to group them
and notify with AUPARSE_CB_EVENT_READY as a consequence.

Now, I write this "fixes" it because if you have a really, really long
hostname, it will fail in the same manner.

--- audit-2.1.3/auparse/auparse.c       2011-08-15 10:31:02.000000000 -0700
+++ audit-2.1.3-cef/auparse/auparse.c   2012-03-06 15:13:13.000000000 -0800
@@ -680,7 +680,7 @@
        int rc = 1;

         e->host = NULL;
-       tmp = strndupa(b, 80);
+       tmp = strndupa(b, 100);
        ptr = strtok(tmp, " ");
        if (ptr) {
                // Optionally grab the node - may or may not be included

A probably better fix is then:
-       tmp = strndupa(b, 80);
+       tmp = strndupa(b, MAX_AUDIT_MESSAGE_LENGTH);

Or:
-       tmp = strndupa(b, 80);
+       tmp = strndup(b); //potentially dangerous?

Or just do away with strtok and avoid duping strings.

Guillaume


On 03/05/2012 04:23 PM, dump@tzib.net wrote:
> Hi,
> 
> I made a audispd plugin, which reads from stdin and sends the strings to
> auparse_feed() (auditd-2.1.3).
> 
> 
> This works fine on the command line.
> 
> When called from audispd however, it gives AUPARSE_CB_EVENT_READY for
> each single message, instead of after a complete event has been parsed.
> 
> So when you have 4 messages for one event:
> - each of them appear as a single event when the plugin is started via
> audispd.
> - a single even for all 4 messages appear when the plugin is started on
> the command line (and the log data fed via stdin, like cat test |
> audispd-testplugin)
> 
> Looking at the write code it looks ok (audisp/audispd.c):
> 
> static int write_to_plugin(event_t *e, const char *string, size_t
> string_len,
> .. (note that i'm using string type so its the string code part)
> if (conf->p->format == F_STRING) {
> do {
> rc = write(conf->p->plug_pipe[1], string, string_len);
> } while (rc < 0 && errno == EINTR);
> }
> 
> Do you know what causes this behavior, and/or how to "fix" it?
> 
> 
> Thanks
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: auparse, stdin, and AUPARSE_CB_EVENT_READY
  2012-03-07 16:50 ` Guillaume Destuynder
@ 2012-03-07 17:19   ` Steve Grubb
  0 siblings, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2012-03-07 17:19 UTC (permalink / raw)
  To: linux-audit

On Wednesday, March 07, 2012 11:50:26 AM Guillaume Destuynder wrote:
> Below patch "fixes" it. The problem is that if you have a node name
> included in the message, and that it's a long hostname, it's just not
> copying a long enough string, and it will fail to parse the message
> serial. When the serial is incorrect, auparse will fail to group them
> and notify with AUPARSE_CB_EVENT_READY as a consequence.
> 
> Now, I write this "fixes" it because if you have a really, really long
> hostname, it will fail in the same manner.

Yes. It looks like we support names up to 255 bytes. So, the "fix" needs more to 
it. This also affects ausearch/report as well. Since this points directly to the 
problem, the real fix should be straight forward.

> Or just do away with strtok and avoid duping strings.

Sure, that's the long term plan. 

-Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: auparse, stdin, and AUPARSE_CB_EVENT_READY
  2012-03-06  0:23 auparse, stdin, and AUPARSE_CB_EVENT_READY dump
  2012-03-07 16:50 ` Guillaume Destuynder
@ 2012-03-07 17:48 ` Steve Grubb
  1 sibling, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2012-03-07 17:48 UTC (permalink / raw)
  To: linux-audit; +Cc: dump

On Monday, March 05, 2012 07:23:32 PM dump@tzib.net wrote:
> Do you know what causes this behavior, and/or how to "fix" it?

This should fix it:
https://fedorahosted.org/audit/changeset?671

-Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-03-07 17:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-06  0:23 auparse, stdin, and AUPARSE_CB_EVENT_READY dump
2012-03-07 16:50 ` Guillaume Destuynder
2012-03-07 17:19   ` Steve Grubb
2012-03-07 17:48 ` Steve Grubb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox