6:23 p.m.
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
10:50 a.m.
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
11:19 a.m.
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
11:48 a.m.
On Monday, March 05, 2012 07:23:32 PM dump(a)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
4620
days inactive
4621
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
dump＠tzib.net -
Guillaume Destuynder -
Steve Grubb