On Monday 08 October 2007 15:45:57 Klaus Weidner wrote:
On Fri, Oct 05, 2007 at 11:11:27AM -0400, Eric Paris wrote:
> My belief is that the solution to this problem is to allow audit to
> break individual arguments down to a size <8k. I guess my syntax would
> be something like
>
> a0[0]=(first 8k of a single huge argument)
> a0[1]=(second 8k of a single huge argument)
[...]
> who has a problem with that syntax? will userspace puke?
I'm a bit worried about special audit record formats that aren't
generally seen in normal operation, since that's an obstacle to
testability.
Well, I take this one to be the same as PATH records. Sometimes you get 1,
sometimes 2, sometimes 3.
The ASCII audit format encourages an ad-hoc parsing approach, and
it's
likely that tools other than the shipped ones won't be able to handle this
and will break unexpectedly, possibly offering avenues to hide events with
unusual records. (I know that people are supposed to use the parsing
library, but they aren't being forced to.)
I also doubt people doing adhoc parsing know the encoding scheme either. So,
they will hit a problem sooner or later.
Would there be a clean way to handle this kind of reassembly in
auditd to
ensure that the on-disk record will continue to be in the currently
documented format?
Well, the record size limit affects realtime interface programs too. They
would all need to be recompiled to handle a bigger record.
Or is there a way to strongly encourage people to keep their hands
off the
raw audit logs and use documented interfaces that take care of the
conversions?
I suppose I could add a note to the daemon's man page. SE Linux has given the
logs a special type and as long as you are not in an unconfined domain, you
shouldn't be able to access it.
-Steve