From: Steve Grubb <sgrubb@redhat.com>
To: Kay Hayen <kayhayen@gmx.de>
Cc: linux-audit@redhat.com, alex@segv.de
Subject: Re: Audit for live supervision
Date: Tue, 19 Aug 2008 14:39:50 -0400 [thread overview]
Message-ID: <200808191439.50621.sgrubb@redhat.com> (raw)
In-Reply-To: <200808192023.21305.kayhayen@gmx.de>
On Tuesday 19 August 2008 14:23:21 Kay Hayen wrote:
> > > > libaudit should pull complete events from the kernel unless an execve
> > > > has an excessive number of arguments or large sized arguments.
> > >
> > > 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?
> >
> > True. You would have to load your own rules since that is done by the
> > audit user space.
>
> Can you confirm that two processes opening netlink sockets for audit
> information get the same messages?
Only one audit pid is allowed for security purposes.
> I am under the impression that the kernel doesn't maintain per socket
> configuration, does it?
Nope, it only allows one.
> If that were the case, we would simply co-exist with auditd and let it do
> its logging, etc. and benefit from it, and its ability to load the rules
If you want to co-exist with auditd, then you want to write your own audispd.
I pointed you to the skeleton.c code in the other email.
> > events. wrt auparse (if that's what you meant) you just run the data
> > through:
> >
> > asprintf(&v, "type=%s msg=%.*s\n", type, e->hdr.size, e->data);
> >
> > and "v" has the string ready for auparse use. asprinf() allocates memory,
> > so watch that it doesn't create a memory leak.
>
> That's very sweet. Where would you expect the pitfalls? I mean, it can't be
> so easy. :-)
No pitfalls except watching for memory leaks. Audispd used the same code.
-Steve
next prev parent reply other threads:[~2008-08-19 18:39 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
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 [this message]
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=200808191439.50621.sgrubb@redhat.com \
--to=sgrubb@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.