From: Steve Grubb <sgrubb@redhat.com>
To: Linda Knippers <linda.knippers@hp.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 20:17:45 -0400 [thread overview]
Message-ID: <200710082017.46614.sgrubb@redhat.com> (raw)
In-Reply-To: <470AB2FB.7020104@hp.com>
On Monday 08 October 2007 18:45:15 Linda Knippers wrote:
> > Well, I take this one to be the same as PATH records. Sometimes you get
> > 1, sometimes 2, sometimes 3.
>
> But for any given system call, wouldn't you always get the same number
> of PATH records?
Maybe, sometimes you get a socket address record, too/instead of. The point is
that you have no idea how many of them you are going to get without some
analysis.
> With PATH records, there's an item count in the SYSCALL record and
> each PATH record says which one it is, so its possible to verify that
> you've gotten them all.
The way these get split, there is no way to know ahead of time how many you
are going to get. These are being split as they are being output. The item
count displayed in syscall is incremented as each aux record data is added to
the context. So, there's no performance cost for displaying this.
We could add an item parameter, but that only gives you sequence information.
But you could infer the sequence information by the argument's number - it
continually increments. If a record ends and a347 and the next one begins at
a895, then you are missing one or more records.
But even then, I don't think that's possible unless someone's tampered with
the logs. If any allocation can't be done, the syscall is failed. So, the
only question is what happens if the netlink queue has a problem sending to
user space? Well, you get a syslog message and the kernel follows the
failure action set by the admin - just as it would for any event.
> I don't see the same type of information for the arguments so its not
> possible to know if you've got a complete audit trail.
When it moves on to another record type, you've got them all.
-Steve
next prev parent reply other threads:[~2007-10-09 0:17 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
2007-10-08 21:41 ` Steve Grubb
2007-10-08 22:45 ` Linda Knippers
2007-10-09 0:17 ` Steve Grubb [this message]
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=200710082017.46614.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linda.knippers@hp.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.