9:38 p.m.
I've been doing some testing of the recent audit cmdline patches,
notably as many as the error paths as I can.
On a failure, the field is populated with null, like when key is null.
However, it has quotes, should I drop the quotes...
Example:
Now:
cmdline="(null)" key=(null)
Proposed:
cmdline=(null) key=(null)
I noticed that tty if its null also does not have quotes.
--
Respectfully,
William C Roberts
9:54 a.m.
On Jan 6, 2014 7:38 PM, "William Roberts" <bill.c.roberts(a)gmail.com>
wrote:
I've been doing some testing of the recent audit cmdline patches,
notably as many as the error paths as I can.
On a failure, the field is populated with null, like when key is null.
However, it has quotes, should I drop the quotes...
Example:
Now:
cmdline="(null)" key=(null)
Proposed:
cmdline=(null) key=(null)
I noticed that tty if its null also does not have quotes.
Also, I was ensuring that the end of cmdline was null terminated before
adding it to the audit buffer. That code is something like:
buf[res-1]=\0
Suppose buf is just a single character. Its within bounds but now gets
clobbered with a null byte? Should I handle this case?
10:34 a.m.
On Monday, January 06, 2014 07:38:02 PM William Roberts wrote:
I've been doing some testing of the recent audit cmdline
patches,
notably as many as the error paths as I can.
On a failure, the field is populated with null, like when key is null.
But (null) for a key field is normal rather than a failure.
However, it has quotes, should I drop the quotes...
Example:
Now:
cmdline="(null)" key=(null)
Proposed:
cmdline=(null) key=(null)
The audit event format cannot change. EVER! If it has been changed due some
patches, it must be changed back as fast as possible. Tools parse the log files
and any format change can cause something important to be missed. Even the
order of fields is important because some tools skip around taking advantage of
the order to speed searches.
So, the correct thing is to make sure events are the same before and after the
patches.
I noticed that tty if its null also does not have quotes.
Quotes are only used when user space has influenced the value. We can't allow a
crafty user/admin to setup fields that will cause a parsing error that hides
and event from tools.
-Steve
1:36 p.m.
On Tue, Jan 7, 2014 at 8:34 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday, January 06, 2014 07:38:02 PM William Roberts wrote:
> I've been doing some testing of the recent audit cmdline patches,
> notably as many as the error paths as I can.
>
> On a failure, the field is populated with null, like when key is null.
But (null) for a key field is normal rather than a failure.
> However, it has quotes, should I drop the quotes...
>
> Example:
>
> Now:
> cmdline="(null)" key=(null)
>
> Proposed:
> cmdline=(null) key=(null)
The audit event format cannot change. EVER! If it has been changed due some
patches, it must be changed back as fast as possible.
I doubt the audit event format has stayed 100% static since it's
inception, so i'm inclined
to disagree with you there. I have also posted the patches numerous
times, and am
working on LKML as well as this list to get all the relevant parts
merged. As of right now
nothing has been merged.
Tools parse the log files
and any format change can cause something important to be missed.
Even the
order of fields is important because some tools skip around taking advantage of
the order to speed searches.
So, the correct thing is to make sure events are the same before and after the
patches.
Not with what I am doing.
> I noticed that tty if its null also does not have quotes.
Quotes are only used when user space has influenced the value. We can't allow a
ok I see that quotes are added as part of audit_log_untrustedstring().
crafty user/admin to setup fields that will cause a parsing error
that hides
and event from tools.
-Steve
What I think I can take away here is this:
1. Any changes to the audit record should append, rather then change orderings
2. The quotes were actually as designed
Any userspace tool that cannot handle the addition of a field in my
mind would be broken.
All of the tools I have been using so far just ignore the extra field
and work fine.
Bill
4001
days inactive
4001
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Steve Grubb -
William Roberts