From: John Dennis <jdennis@redhat.com>
To: Kay Hayen <kayhayen@gmx.de>
Cc: alex@segv.de, linux-audit@redhat.com
Subject: Re: Audit for live supervision
Date: Tue, 19 Aug 2008 10:14:54 -0400 [thread overview]
Message-ID: <48AAD55E.5070408@redhat.com> (raw)
In-Reply-To: <200808190845.01023.kayhayen@gmx.de>
[-- Attachment #1.1: Type: text/plain, Size: 2382 bytes --]
Kay Hayen wrote:
> No, when opening the socket the to the sub deamon audisp. I couldn't convice
> myself how the API would work with a socket. Does it?
>
The auparse library can read a stream by opening the parser with
AUSOURCE_FEED, you set a callback, then feed arbitrary number of bytes
into the parser by calling auparse_feed(), you'll be called back when a
complete event is found, at that point just use the normal auparse
functions.
You can read off of this unix socket (/var/run/audispd_events) but this
is deprecated. It is now preferred is now to use a audispd plugin and
read from stdin. See the audit src package and look in audisp/plugins
for examples. FWIW I noticed that code was calling fgets to get data to
feed to auparse_feed() but it seems inefficient to buffer lines twice,
auparse_feed will do the line protocol.
> I read that as that we can use the netlink socket with the libaudit directly,
> which sort of could be exactly what we want. That would mean we wouldn't use
> audit user space (processes) at all, right?
>
>
No, you really want to use the user space interface (see above).
>
>> You have 4 points to get the audit stream, in order of distance from the
>> event generation: the audit netlink socket, auditd realtime interface,
>> audisp plugin interface, and the af_unix socket created by the af_unix
>> plugin from audispd. For higher reliability where you don't want of need
>> any other audit processing interfering, I would say use either of the first
>> 2.
>>
>
> The latency is getting higher with each step. For optimal performance we would
> listen to the netlink socket and duplicate only the code essential to process
> what we are interested it.
>
> For extra points and hurt, we would do it in Ada and inside the target
> process, really achieving the low latency. It may be the only realistic
> option, but it also feels like duplication of effort. We have done netlink
> interfaces in Ada before, but also have on our mind that it was said that the
> netlink interface was said (not by you) to be still in flux. Is that still
> true?
>
> It certainly would be nice if the audisp had some form of output that can be
> fed directly into libaudit parsing as it comes in. But that may be an
> unrealistic expectation, is it?
>
>
It does, see above comment.
--
John Dennis <jdennis@redhat.com>
[-- Attachment #1.2: Type: text/html, Size: 3085 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2008-08-19 14:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 7:14 Audit for live supervision Kay Hayen
2008-08-14 14:04 ` Steve Grubb
2008-08-15 6:43 ` Kay Hayen
2008-08-15 12:54 ` Steve Grubb
2008-08-16 11:19 ` Kay Hayen
2008-08-18 15:10 ` Steve Grubb
2008-08-19 6:45 ` Kay Hayen
2008-08-19 14:14 ` John Dennis [this message]
2008-08-19 17:46 ` Kay Hayen
2008-08-19 18:18 ` Steve Grubb
2008-08-19 14:47 ` Steve Grubb
2008-08-19 18:23 ` Kay Hayen
2008-08-19 18:39 ` Steve Grubb
2008-08-19 20:33 ` Kay Hayen
2008-08-19 20:47 ` Steve Grubb
2008-08-19 21:35 ` Kay Hayen
2008-08-19 21:47 ` Steve Grubb
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=48AAD55E.5070408@redhat.com \
--to=jdennis@redhat.com \
--cc=alex@segv.de \
--cc=kayhayen@gmx.de \
--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.