9:43 a.m.
Recently I've been switching over my embedded distro to relying on
systemd for logging. The thought crossed my mind that it would be
convenient if auditd supported storing log information in systemd's
journal with the sd-journal API. It would be great if syslog data and
audit log data were stored in systemd's journal so common a interface
could be used to query, send alerts, generate reports, etc.
I suppose several different approaches could be taken:
1) Use audispd's builtin syslog plugin to send the events to syslog
which in my case would be systemd storing them to the journal. The
problem with this would be that all of the event information would be
stored in the message, it would be much more useful if each audit log
field resulted in a journal field.
2) Write an audispd plugin that used the sd-journal API to store
audit events in the journal.
3) Add sd-journal as a log format to auditd.
Does anyone have any thoughts/comments on why this would be either a
good or bad idea? Further more if I don't receive convincing arguments
why this shouldn't be I'll probably take a shot a write a patch to add
it, so any tips/suggestions relevant would be greatly appreciated.
Thanks,
George McCollister
10:22 a.m.
----- Original Message -----
2) Write an audispd plugin that used the sd-journal API to store
audit events in the journal.
3) Add sd-journal as a log format to auditd.
Both of these will run into the problem recently discussed on this mailing list: the
available methods to parse an audit records into fields are a bit
imprecise/"lossy" because not all records keep the name=value format as
expected.
This can be OK if auparse is able to extract all the data you need/expect to process.
Mirek
11:54 a.m.
On Friday, March 15, 2013 11:22:50 AM Miloslav Trmac wrote:
----- Original Message -----
> 2) Write an audispd plugin that used the sd-journal API to store
>
> audit events in the journal.
>
> 3) Add sd-journal as a log format to auditd.
Both of these will run into the problem recently discussed on this mailing
list: the available methods to parse an audit records into fields are a bit
imprecise/"lossy" because not all records keep the name=value format as
expected.
I don't think this is a problem to worry about. A plugin is handed the whole
event line by line. To push events you don't need to parse. The real issue is
later...running reports.
I also thought there was some patch presented on this list sometime in the
last month to allow journald to listen for audit events directly.
-Steve
3:58 p.m.
On Fri, 2013-03-15 at 12:54 -0400, Steve Grubb wrote:
On Friday, March 15, 2013 11:22:50 AM Miloslav Trmac wrote:
> ----- Original Message -----
>
> > 2) Write an audispd plugin that used the sd-journal API to store
> >
> > audit events in the journal.
> >
> > 3) Add sd-journal as a log format to auditd.
>
> Both of these will run into the problem recently discussed on this mailing
> list: the available methods to parse an audit records into fields are a bit
> imprecise/"lossy" because not all records keep the name=value format as
> expected.
I don't think this is a problem to worry about. A plugin is handed the whole
event line by line. To push events you don't need to parse. The real issue is
later...running reports.
I also thought there was some patch presented on this list sometime in the
last month to allow journald to listen for audit events directly.
That's correct. There is work to pass audit messages directly from the
kernel to the journal. But it isn't ready. Today, your best bet if you
are doing it yourself is any of the above, but I don't know which one...
4294
days inactive
4299
days old
linux-audit@lists.linux-audit.osci.io
3 comments
4 participants
participants (4)
-
Eric Paris -
George McCollister -
Miloslav Trmac -
Steve Grubb