11:58 p.m.
Steve has asked me to write the audit dispatcher, and after talking
about it we already have some plans (as you'll see below :) but we would
welcome input from people on this list.
First to bring you all up to speed with what we know:
. Development should be starting soon.
. It will, at least initially, be distributed as part of the audit
package.
. We are planning to have a usable version for Fedora 7.
. That initial version will be able to act as the dispatcher for auditd
and (re-)send those messages to multiple plugins.
. Those plugins can be shipped separately.
...and what seems very likely:
. The plugins will be external applications.
. The dispatcher itself will not be parsing audit messages and will be
designed as a kind of Publish/Subscribe daemon.
. In that vein, reuse of code from And-httpd/Vstr/etc.[1] is more than
very likely.
. The dispatcher will only be doing minimal content filtering for the
plugins (this kind of falls out from the minimal parsing).
. That message input will come from plugins, as well as the output.
. They'll be a mode for the plugin to run in where it speaks a
mini-protocol with the dispatcher, instead of just getting raw messages
from auditd.
. That the mini-protocol will allow "commands" to go back to the
dispatcher (think remote server says "out of disk space, do X" or IDS
says "attack happening from IP block X/y, do Z").
. The initial set of plugins will contain at least something to connect
the dispatcher to setroubleshootd and something for (secure) remote
logging.
I've probably missed something already, so if there's anything you want
that isn't on the above list or anything that isn't clear and you want
to clarify ... just hit reply :).
[1] http://www.and.org/and-httpd/ and http://www.and.org/vstr/
--
James Antill - <james.antill(a)redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...);
8:56 a.m.
On Thursday 11 January 2007 00:58, James Antill wrote:
It will, at least initially, be distributed as part of the audit
package.
It will be distributed in the audit package as will a set of common plugins.
Third parties can write their own just as pam modules can be distributed for
the pam system.
Those plugins can be shipped separately.
Well, a common set will be part of the audit system. See below.
. The plugins will be external applications.
Yes, to be good selinux citizens, this will be necessary.
. That message input will come from plugins, as well as the output.
The idea is that the dispatcher and plugins will be the transport mechanism
for log aggregation. Most machines would have as sending plugin, while one
machine would be receiving the events for logging. There is also a desire to
be able to pull in iptables events for other plugins that would like to
analyze these events for security purposes.
. They'll be a mode for the plugin to run in where it speaks a
mini-protocol with the dispatcher, instead of just getting raw messages
from auditd.
. That the mini-protocol will allow "commands" to go back to the
dispatcher (think remote server says "out of disk space, do X" or IDS
says "attack happening from IP block X/y, do Z").
Right. If we are doing remote logging and the remote machine runs out of disk
space, the plugin will have to handle the admin selected action such as
single user mode, halt, etc. I do not want a 2 way communication system with
the audit daemon itself. This complicates its code for CAPP/LSPP analysis and
testing. So, the receive plugin will need to ack everything its getting and
the senders will need to wait for that ack. Also, need to consider what to do
when reboot of the aggregator occurs. Should they spool, if so how much, etc.
. The initial set of plugins will contain at least something to
connect
the dispatcher to setroubleshootd and something for (secure) remote
logging.
Right, I see these as the initial common set:
1) setroubleshootd adapter to feed events to it.
2) remote logging plugin to send events to remote machine. This should use ssl
to keep events private.
3) syslog plugin - simply takes events and writes to syslog
4) iptables event input plugin
5) remote logging receive plugin
6) possibly a filter plugin that can do matching for certain kinds of events
and send notification when it sees that event. (not a high priority and could
be added later depending on how long the others take.) Analogous to grep.
Other requirements:
plugin installation should be such that they are installed in a way that does
not require editing the master config file. Perhaps each plugin is required
to put a config file in /etc/audipsd.d directory which includes at a minimum
path to binary and whether or not its enabled (like xinetd).
Dependencies on external libraries should be kept to a minimum and optional by
configure options.
dispatcher interface with auditd has to conform to guidelines here:
http://people.redhat.com/sgrubb/audit/audit-rt-events.txt
config file parsing should use libaudit's parsing code. I'd like to keep a
consistent style among pieces of the audit system.
If I think of other things I'll add them later.
Thanks,
-Steve
1:13 p.m.
On Thu, 2007-01-11 at 09:56 -0500, Steve Grubb wrote:
So, the receive plugin will need to ack everything its getting and
the senders will need to wait for that ack. Also, need to consider what to do
when reboot of the aggregator occurs. Should they spool, if so how much, etc.
This is all contained in the remote plugin, or do you want a general
ACK'ing process all the way back to any input plugins. Ie.
input plugin =>
dispatcher =>
remote logging plugin =>
remote server =>
disk "ACK" =>
remote server <=
remote logging plugin <=
-- stop here? --
dispatcher <=
-- or stop here? --
input plugin <=
-- or even stop here? --
...even if we just stop at the remote logging plugin level, are we
worried about duplicate entries on the logging server?
I guess that's better than missing entries if the power fails on the
logging server (I just don't want to have to solve the two generals
problem :).
Other requirements:
plugin installation should be such that they are installed in a way that does
not require editing the master config file. Perhaps each plugin is required
to put a config file in /etc/audipsd.d directory which includes at a minimum
path to binary and whether or not its enabled (like xinetd).
Yeh, I'm meant to say that with the shipped separately point. One thing
I'm not sure about is if there's a requirement to pickup new
changes/plugins without having to "reboot" the dispatcher in some way.
I'd also thought of having the auditd input be a plugin itself, this
way you could quickly reboot the dispatcher while the auditd input
plugin spooled the incoming data for a small period of time. This might
make signal handling simpler too, although it's certainly not in the
spirit of the dispatcher :).
Dependencies on external libraries should be kept to a minimum and
optional by
configure options.
Well, if by optional you mean "something doesn't get built". Then, yeh,
I'd planned to do that ... but I'm not sure how useful it'll be, esp.
with regard to any deps needed for the dispatcher itself.
dispatcher interface with auditd has to conform to guidelines here:
http://people.redhat.com/sgrubb/audit/audit-rt-events.txt
Ahh thanks, I'd looked at the libaudit.h header and worked out most of
the above but the clarification is appreciated.
One question though: Should I just take the first 4 bytes, and compare
to zero then take the next 12 ... or just grab the first 16, I figured
from the .h file that the first 16 will always be there but the above
page suggests just checking the first 32 bits (note s/32 bytes/32 bits/
to fix the typo).
config file parsing should use libaudit's parsing code. I'd
like to keep a
consistent style among pieces of the audit system.
From what I can see of audit.conf and that code, it would be extremely
hard to use for what we'd want to do with plugins. IMO the audit daemon
and the dispatcher do very different jobs, so a different config. file
syntax isn't a problem, and setroubleshoot already has a totally
different config. style.
The conf code from And-httpd should be very easy to reuse for this
(it's used to configure similar types of applications), already supports
conf.d directories, already supports building paths from pieces of
dynamic information etc.
--
James Antill <jantill(a)redhat.com>
3:30 p.m.
On Thursday 11 January 2007 14:13, James Antill wrote:
On Thu, 2007-01-11 at 09:56 -0500, Steve Grubb wrote:
> So, the receive plugin will need to ack everything its getting and
> the senders will need to wait for that ack. Also, need to consider what
> to do when reboot of the aggregator occurs. Should they spool, if so how
> much, etc.
This is all contained in the remote plugin, or do you want a general
ACK'ing process all the way back to any input plugins.
I'm thinking just the two that do the remote logging transfer.
...even if we just stop at the remote logging plugin level, are we
worried about duplicate entries on the logging server?
I'd rather not have them.
I guess that's better than missing entries if the power fails on
the
logging server (I just don't want to have to solve the two generals
problem :).
True. But we don't want to make something too complicated either. Complicated
makes it hard to analyze for failure modes and effects.
> Other requirements:
>
> plugin installation should be such that they are installed in a way that
> does not require editing the master config file. Perhaps each plugin is
> required to put a config file in /etc/audipsd.d directory which includes
> at a minimum path to binary and whether or not its enabled (like xinetd).
Yeh, I'm meant to say that with the shipped separately point. One thing
I'm not sure about is if there's a requirement to pickup new
changes/plugins without having to "reboot" the dispatcher in some way.
Yes. The desired way to do this is SIGHUPing the audit daemon. It will inform
the dispatcher and it will do its magic.
I'd also thought of having the auditd input be a plugin itself,
this
way you could quickly reboot the dispatcher while the auditd input
plugin spooled the incoming data for a small period of time.
No need for this. The audit daemon has to start the dispatcher so it will have
a pipe between the processes. There's no way to insert a plugin between the
two without making life complicated.
> Dependencies on external libraries should be kept to a minimum
and
> optional by configure options.
Well, if by optional you mean "something doesn't get built". Then, yeh,
right.
I'd planned to do that ... but I'm not sure how useful
it'll be, esp.
with regard to any deps needed for the dispatcher itself.
There should be no external libraries needed for it. Its too simple to need
anything external. The plugins may need openssl or nss. Actually nss might be
a better choice since its FIPS 140-2 certified. But we can talk about that
when we get there.
One question though: Should I just take the first 4 bytes, and
compare
to zero then take the next 12 ... or just grab the first 16,
I'd make a pointer of uint32_t type and cast it to the data's pointer. Then
you can check its contents and decide if you know how to handle data of that
type. Odds are it will always be in sync because its being distributed with
the audit daemon. The note in the specification is there mostly for the
benefit of third party dispatchers since the audit daemon could have been
upgraded. So, in reality, I don't think you have to worry about it so much.
Any other author will, though.
> config file parsing should use libaudit's parsing code.
I'd like to keep
> a consistent style among pieces of the audit system.
From what I can see of audit.conf and that code, it would be extremely
hard to use for what we'd want to do with plugins. IMO the audit daemon
and the dispatcher do very different jobs,
Yes.
so a different config. file syntax isn't a problem, and
setroubleshoot
already has a totally different config. style.
Well, that's a whole different package, though.
The conf code from And-httpd should be very easy to reuse for this
(it's used to configure similar types of applications), already supports
conf.d directories, already supports building paths from pieces of
dynamic information etc.
Hmm...I hadn't wanted to pull in dependencies due to needing to do external
code reviews. What kind of syntax needs do you think we really need? I'm open
to ideas. The plugins I would envision might need to read their own config
files. They might have complicated needs, but I don't think the dispatcher
would.
-Steve
6555
days inactive
6555
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
James Antill -
Steve Grubb