From: Klaus Weidner <klaus@atsec.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-audit@redhat.com, a.p.zijlstra@chello.nl
Subject: Re: [PATCH 2/2] Audit: remove the limit on execve arguments when audit is running
Date: Mon, 8 Oct 2007 14:45:57 -0500 [thread overview]
Message-ID: <20071008194557.GA32746@w-m-p.com> (raw)
In-Reply-To: <1191597087.3198.7.camel@dhcp231-215.rdu.redhat.com>
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. 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.)
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? 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?
-Klaus
next prev parent reply other threads:[~2007-10-08 19:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-02 21:29 [PATCH 2/2] Audit: remove the limit on execve arguments when audit is running Eric Paris
2007-10-03 16:56 ` Peter Zijlstra
2007-10-05 15:11 ` Eric Paris
2007-10-05 15:44 ` Steve Grubb
2007-10-08 19:45 ` Klaus Weidner [this message]
2007-10-08 21:41 ` Steve Grubb
2007-10-08 22:45 ` Linda Knippers
2007-10-09 0:17 ` Steve Grubb
2007-10-09 2:34 ` Linda Knippers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071008194557.GA32746@w-m-p.com \
--to=klaus@atsec.com \
--cc=a.p.zijlstra@chello.nl \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.