2:48 p.m.
Hello,
I am attaching an Open Office presentation that contains the slides for the
audit dispatcher preliminary design review. The audit dispatcher will be
implemented using C++ to provide some organization and abstraction for some
of the design elements.
The audit dispatcher will be configured by a file /etc/audisp.conf that will
instruct it on how to configure the input plugins and the output filter
plugin. Some plugins will be active - meaning that they have their own thread
of execution. Others will be passive and use the caller's thread.
The Filter plugin is a Composite of two classes - The filter and an output.
The filter part does the data transformation or filtering. The output plugin
takes the data passed to it and outputs it. The plugin class is a wrapper for
a shared object file that gets loaded and unloaded.
Events will be gathered by input plugins and placed into the applications
event queue. Filter plugins will have previously registered for callbacks for
new events. They will all receive the event and begin processing it. When and
if the event needs to be output, the filter will call its output plugin.
The audisp daemon will receive a reconfigure event whenever SIGHUP is sent to
the audit daemon. It will re-read its config and remove, add, or modify
plugins on the fly.
There are some rules regarding the implementation in C++. The ground rules
are: No dynamic class creation or deletion except at startup/shutdown; No
exceptions; and No templates.
This is a preliminary design. If there are any concerns, comments,
suggestions, please follow up on this. This was modeled with Umbrello - which
is part of Kdesdk. The PDR model will be placed on
people.redhat.com/~sgrubb/audit.
Thanks,
-Steve Grubb
1:33 p.m.
On Friday 02 September 2005 14:48, Steve Grubb wrote:
Hello,
I am attaching an Open Office presentation that contains the slides for the
audit dispatcher preliminary design review. The audit dispatcher will be
implemented using C++ to provide some organization and abstraction for some
of the design elements.
The audit dispatcher will be configured by a file /etc/audisp.conf that will
instruct it on how to configure the input plugins and the output filter
plugin. Some plugins will be active - meaning that they have their own thread
of execution. Others will be passive and use the caller's thread.
The Filter plugin is a Composite of two classes - The filter and an output.
The filter part does the data transformation or filtering. The output plugin
takes the data passed to it and outputs it. The plugin class is a wrapper for
a shared object file that gets loaded and unloaded.
Events will be gathered by input plugins and placed into the applications
event queue. Filter plugins will have previously registered for callbacks for
new events. They will all receive the event and begin processing it. When and
if the event needs to be output, the filter will call its output plugin.
The audisp daemon will receive a reconfigure event whenever SIGHUP is sent to
the audit daemon. It will re-read its config and remove, add, or modify
plugins on the fly.
There are some rules regarding the implementation in C++. The ground rules
are: No dynamic class creation or deletion except at startup/shutdown; No
exceptions; and No templates.
This is a preliminary design. If there are any concerns, comments,
suggestions, please follow up on this. This was modeled with Umbrello - which
is part of Kdesdk. The PDR model will be placed on
people.redhat.com/~sgrubb/audit.
Thanks,
-Steve Grubb
1:45 p.m.
On Friday 02 September 2005 14:48, Steve Grubb wrote:
Hello,
I am attaching an Open Office presentation that contains the slides for the
audit dispatcher preliminary design review. The audit dispatcher will be
implemented using C++ to provide some organization and abstraction for some
of the design elements.
Just a note:
AFAIK the OpenDocument Presentation (ODP) file format is not supported in
OpenOffice 1.0/1. For a list of applications that do support this file format
(including OpenOffice 2) check here,
http://en.wikipedia.org/wiki/OpenDocument#Applications_supporting_OpenDoc...
The audit dispatcher will be configured by a file /etc/audisp.conf that will
instruct it on how to configure the input plugins and the output filter
plugin. Some plugins will be active - meaning that they have their own thread
of execution. Others will be passive and use the caller's thread.
Will auditd require audisp be running or will the absence of audisp produce a
default behavior in auditd?
The Filter plugin is a Composite of two classes - The filter and an output.
The filter part does the data transformation or filtering. The output plugin
takes the data passed to it and outputs it. The plugin class is a wrapper for
a shared object file that gets loaded and unloaded.
Events will be gathered by input plugins and placed into the applications
event queue. Filter plugins will have previously registered for callbacks for
new events. They will all receive the event and begin processing it. When and
if the event needs to be output, the filter will call its output plugin.
The audisp daemon will receive a reconfigure event whenever SIGHUP is sent to
the audit daemon. It will re-read its config and remove, add, or modify
plugins on the fly.
There are some rules regarding the implementation in C++. The ground rules
are: No dynamic class creation or deletion except at startup/shutdown; No
exceptions; and No templates.
This is a preliminary design. If there are any concerns, comments,
suggestions, please follow up on this. This was modeled with Umbrello - which
is part of Kdesdk. The PDR model will be placed on
people.redhat.com/~sgrubb/audit.
Thanks,
-Steve Grubb
I think it might be useful to spend 30m/1hr on the phone / IRC going over
these diagrams for all parties interested (*raises hand*). This would be
more helpful for me, at least.
-tim
4:57 p.m.
Timothy R. Chavez wrote:
Will auditd require audisp be running or will the absence of audisp
produce a
default behavior in auditd?
I was wondering about that too. Is this an optional part of the audit
subsystem or a replacement of the existing implementation?
I was also wondering about the overall design goals, how we'd expect
this to be used and what the performance and error handling
characteristics would be.
-- ljk
8:09 p.m.
Hi,
Steve is away a couple of days so I'm responding to your mail
since I originally proposed the audit event filtering with plugins.
>Will auditd require audisp be running or will the absence of
audisp produce a
>default behavior in auditd?
I was wondering about that too. Is this an optional part of the audit
subsystem or a replacement of the existing implementation?
Audisp will be running as different process, it won't hurt any current
auditd implementation. If you don't need audisp then you can just
disable it.
Audisp and auditd will be communicating thru pipes when they are
configured to use pipe. There will be networked filtering/output
plugins too.
I was also wondering about the overall design goals, how we'd
expect
this to be used and what the performance and error handling
characteristics would be.
It can be used many ways. For example, if you want to filter kernel
audit messages to audit some system security errors then
what you can do now is just to read logs and find message by hand.
With audisp you can filter audit messages and dispatch them.
For instance, if you want to audit:
1) AVC error messages to generate policy using audit2allow
2) Keep checking if someone's modified /var/www/htdocs/index.html
Then, with audisp, you can have filter plugins to detect them and
output where you want, i.e. output using alert box on desktop,
sending emails to admin, etc.
We are still in design phase so please let us know if you have requests
and questions.
Thanks,
-- Junji Kanemaru
CEO Linuon Inc.
Tokyo Japan
8:35 a.m.
On Wednesday 07 September 2005 17:57, Linda Knippers wrote:
I was also wondering about the overall design goals, how we'd
expect this to
be used
That was stated here:
https://www.redhat.com/archives/linux-audit/2005-August/msg00073.html
and what the performance and error handling characteristics would be.
No performance goal. There is a queue between auditd & audisp to decouple the
rate of processing.
What can you say about error handling other than it must be correct? auditd is
not going away. It will be the method for reliable logging. audisp is going
to be best effort at this point. For example, if you use remote logging
should the machine stop if the network goes down? Should it queue them and
transfer when the network is up? What if the queue fills to capacity? If the
remote logger's disk is full, should all machines on the network go to admin
mode? That'll be a bummer. I don't think we want to face all these issues and
claim 100% guarantee at this point.
-Steve
12:55 p.m.
On Thu, 08 Sep 2005 09:35:32 EDT, Steve Grubb said:
What can you say about error handling other than it must be correct?
auditd is
not going away. It will be the method for reliable logging. audisp is going
to be best effort at this point. For example, if you use remote logging
should the machine stop if the network goes down? Should it queue them and
transfer when the network is up? What if the queue fills to capacity? If the
remote logger's disk is full, should all machines on the network go to admin
mode? That'll be a bummer. I don't think we want to face all these issues and
claim 100% guarantee at this point.
I can't speak for others, but I can certainly live with best-effort for audisp,
as long as I can still configure auditd so we guarantee it locks up if we can't
generate at least *one* reliable log.
How much can we do for reliable *detection* of failure on audisp's part? For
instance, use a TCP connection, and syslog or something if we see an
EWOULDBLOCK (I know, not perfect, as it won't actually trip until we've sent
at least a window's worth of data if the other end glorbles up - but probably
good enough for my needs, and as good as it gets without an explicit ACK)....
6:02 p.m.
Steve Grubb wrote:
On Wednesday 07 September 2005 17:57, Linda Knippers wrote:
>I was also wondering about the overall design goals, how we'd expect this to
>be used
That was stated here:
https://www.redhat.com/archives/linux-audit/2005-August/msg00073.html
Sorry, I completely forgot about the first message by the time I read
the second. :-(
Would the default behavior be that the audisp isn't used, so the auditd
writes the records to disk the way is does today? Is it the case where
one chooses between the current behavior or sending everything to the
dispatcher? Or is there a case where auditd still writes to the audit
log but also sends the records to the pipe?
>and what the performance and error handling characteristics would
be.
No performance goal. There is a queue between auditd & audisp to decouple the
rate of processing.
Would you worry about flow control? Pipes can back up so would you log
something if you're dropping messages between the two daemons?
What can you say about error handling other than it must be correct?
auditd is
not going away. It will be the method for reliable logging.
If that's the case (I wasn't sure before) then I'm less worried although
I'd still be concerned about backups between auditd and audisp impacting
the reliable logging, and also the overall performance impact on the
system. Will the audit dispatcher be usable with the data moving
around so much? Or could it actually be better because you could be
reducing the data along the way and writing less to disk? That's why I
was wondering what the real objective is.
audisp is going
to be best effort at this point. For example, if you use remote logging
should the machine stop if the network goes down? Should it queue them and
transfer when the network is up? What if the queue fills to capacity? If the
remote logger's disk is full, should all machines on the network go to admin
mode? That'll be a bummer. I don't think we want to face all these issues and
claim 100% guarantee at this point.
There's probably no one right answer. Looks like a couple of knobs
for each type of plugin.
-- ljk
8:56 p.m.
On Thursday 08 September 2005 19:02, Linda Knippers wrote:
Would the default behavior be that the audisp isn't used, so the
auditd
writes the records to disk the way is does today?
Probably not. But that's how you would configure it for CAPP.
Is it the case where one chooses between the current behavior or
sending
everything to the dispatcher?
No, you now have 4 choices: no logging but eat meassages, auditd logging,
audisp logging, or both audisp & auditd.
Or is there a case where auditd still writes to the audit log but
also sends
the records to the pipe?
Yes. This would be the likely case.
> No performance goal. There is a queue between auditd &
audisp to decouple
> the rate of processing.
Would you worry about flow control? Pipes can back up so would you log
something if you're dropping messages between the two daemons?
I was planning to make the pipe action configurable so that you can have
either "best effort" or "try harder". Best effort would be used for
local
logging since you don't really care as much about anything else. If you
disable local logging, then audisp could be blocking writes since its now
more important.
Will the audit dispatcher be usable with the data moving around so
much?
Sure.
Or could it actually be better because you could be reducing the data
along
the way and writing less to disk?
Not sure.
That's why I was wondering what the real objective is.
There's lots of people wanting to get their hands on events in realtime to
react to something. That's what its all about.
-Steve
8:04 a.m.
On Tuesday 06 September 2005 14:45, Timothy R. Chavez wrote:
Just a note:
AFAIK the OpenDocument Presentation (ODP) file format is not supported in
OpenOffice 1.0/1. For a list of applications that do support this file
format (including OpenOffice 2) check here,
Right. I forgot to mention that. I am on a FC4 machine at this point. It has
all the utilities to read the material. I'll mention that on the web page.
> The audit dispatcher will be configured by a file
/etc/audisp.conf that
> will instruct it on how to configure the input plugins and the output
> filter plugin. Some plugins will be active - meaning that they have their
> own thread of execution. Others will be passive and use the caller's
> thread.
Will auditd require audisp be running
No.
or will the absence of audisp produce a default behavior in auditd?
With or without audisp, auditd behavior is not changed. That was one of the
design goals in the requirements I sent to the mail list 2 weeks ago.
I think it might be useful to spend 30m/1hr on the phone / IRC going
over
these diagrams for all parties interested (*raises hand*). This would be
more helpful for me, at least.
Too much to explain for IRC. The text is a basic narration for the slides. I
can go over it next time we speak. Or f there's a lot of demand, maybe a 20
minute telecon could be set up.
-Steve
10:53 a.m.
On Thursday 08 September 2005 08:04, Steve Grubb wrote:
On Tuesday 06 September 2005 14:45, Timothy R. Chavez wrote:
<snip>
> I think it might be useful to spend 30m/1hr on the phone / IRC going over
> these diagrams for all parties interested (*raises hand*). This would be
> more helpful for me, at least.
Too much to explain for IRC. The text is a basic narration for the slides. I
can go over it next time we speak. Or f there's a lot of demand, maybe a 20
minute telecon could be set up.
-Steve
If I'm the only one that wants you to go over them, then we can just do it the
next time we talk. If others step forward and our interested, we can go ahead
and schedule a short telecon.
-tim
11:20 a.m.
On Thu, Sep 08, 2005 at 09:04:40AM -0400, Steve Grubb wrote:
On Tuesday 06 September 2005 14:45, Timothy R. Chavez wrote:
> Just a note:
>
> AFAIK the OpenDocument Presentation (ODP) file format is not supported in
> OpenOffice 1.0/1. ?For a list of applications that do support this file
> format (including OpenOffice 2) check here,
Right. I forgot to mention that. I am on a FC4 machine at this point. It has
all the utilities to read the material. I'll mention that on the web page.
You could also provide an .sxi version of the slides.
Thanks,
Amy
7043
days inactive
7050
days old
linux-audit@lists.linux-audit.osci.io
11 comments
6 participants
participants (6)
-
Amy Griffis -
Junji Kanemaru -
Linda Knippers -
Steve Grubb -
Timothy R. Chavez -
Valdis.Kletnieks＠vt.edu