--- linux-2.6.11/kernel/auditsc.c~ 2005-03-16 22:13:22.000000000 +0100
+++ linux-2.6.11/kernel/auditsc.c 2005-03-16 22:13:22.000000000 +0100
@@ -612,9 +612,6 @@
if (!ab)
continue; /* audit_panic has been called */
audit_log_format(ab, "item=%d", i);
- if (context->names[i].name)
- audit_log_format(ab, " name=%s",
- context->names[i].name);
if (context->names[i].ino != (unsigned long)-1)
audit_log_format(ab, " inode=%lu",
context->names[i].ino);
@@ -624,6 +621,9 @@
audit_log_format(ab, " dev=%02x:%02x",
MAJOR(context->names[i].rdev),
MINOR(context->names[i].rdev));
+ if (context->names[i].name)
+ audit_log_format(ab, " name=%s",
+ context->names[i].name);
audit_log_end(ab);
}
}
* Ondrej Zary ([email protected]) wrote:
> This patch moves the "name=" field to the end of audit records. The
> original placement is bad because it cannot be properly parsed. It is
> impossible to tell if the name is "/bin/true" or "/bin/true inode=469634
> dev=00:00" because the "inode=" and "dev=" fields can be omitted.
>
> Before:
> audit(1111008486.824:89346): item=0 name=/bin/true inode=469634 dev=00:00
>
> After:
> audit(1111008486.824:89346): item=0 inode=469634 dev=00:00 name=/bin/true
>
> Signed-off-by: Ondrej Zary <[email protected]>
Looks reasonable. Thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Wed, 2005-03-16 at 14:41 -0800, Chris Wright wrote:
> * Ondrej Zary ([email protected]) wrote:
> > This patch moves the "name=" field to the end of audit records. The
> > original placement is bad because it cannot be properly parsed. It is
> > impossible to tell if the name is "/bin/true" or "/bin/true inode=469634
> > dev=00:00" because the "inode=" and "dev=" fields can be omitted.
Consider:
open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
I don't think this patch is enough -- either we need to escape the text
completely or just dump it as hex instead of a string. One option would
be to dump it in quotes as a string if all chars in the string are in
the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
parsing, but not by much, and still gives you plain text in the majority
of cases while protecting against abuse.
--
dwmw2
* David Woodhouse ([email protected]) wrote:
> On Wed, 2005-03-16 at 14:41 -0800, Chris Wright wrote:
> > * Ondrej Zary ([email protected]) wrote:
> > > This patch moves the "name=" field to the end of audit records. The
> > > original placement is bad because it cannot be properly parsed. It is
> > > impossible to tell if the name is "/bin/true" or "/bin/true inode=469634
> > > dev=00:00" because the "inode=" and "dev=" fields can be omitted.
>
> Consider:
>
> open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
>
> I don't think this patch is enough -- either we need to escape the text
> completely or just dump it as hex instead of a string. One option would
> be to dump it in quotes as a string if all chars in the string are in
> the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
> parsing, but not by much, and still gives you plain text in the majority
> of cases while protecting against abuse.
Yes good point. I don't have a strong preference. Steve, are you
working on processing log data, do you have a preference?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Thursday 17 March 2005 12:57, Chris Wright wrote:
> Steve, are you working on processing log data, do you have a preference?
Yes, I am working on a utility to process the data. I have 4 comments:
1) Fields that magically appear and dissappear are problematic for fast
parsing.
2) There should be a way to control what fields the kernel emits. The
dissappearing fields are what I take to be a stab at message compression. By
having a mask driven approach and always emitting those fields, we can parse
faster and have compression.
3) Fields that potentially have a space, tab, or carriage return in them need
escaping or quoting if they are sent in human readable format.
4) There should be a mode/format status variable so that in the future we can
tell the kernel to switch to another (binary) format. This way human readable
records can go to syslog and special apps like the audit daemon can switch to
another format (binary data ?) which might be more efficient. I haven't spent
anytime looking at what makes sense for a binary format, nor do we have time
for that right now. But I'd like to look at that in the future.
-Steve Grubb