POSIX Event Logging, kernel 2.5.6 & 2.4.18
Please cc: [email protected] with your comments.
Patch for kernel version 2.5.6:
http://prdownloads.sourceforge.net/evlog/evlog-1.3.0_kernel2.5.6.patch
Patch for kernel version 2.4.17, 2.4.18:
http://prdownloads.sourceforge.net/evlog/evlog-1.3.0_kernel2.4.17.patch
This patch, in combination with the event logging and event notification user library, provides a comprehensive event logging package based on the draft POSIX standard 1003.25. See http://evlog.sourceforge.net/ for details and downloads.
A summary of the kernel patch:
1) A static kernel buffer is implemented for POSIX events logged in the kernel. Size is configurable during kernel build.
2) If the buffer overruns the oldest events are kept, newest discarded, and a count of discarded events is reported.
3) Optionally, POSIX events can be created from printk messages (printk messages still go to /var/log/messages, as before)
4) Functions are provided for:
- logging directly to kernel event buffer (text string or binary data which gets formatted outside of the kernel)
- registering facilities beyond the standard ones in syslog.h (device drivers can have facility other than KERN)
5) Events are displayed on the system console as single-line summary messages (based on printk's default console logging level).
Please be clear that this is NOT intended to replace printk and syslog, but to coexist with them and provide additional capabilities not available with printk/syslog that are highly desirable in large servers and Telecom environments (to name a few).
Larry Kessler
Quoted 2 lines · Larry Kessler
2) If the buffer overruns the oldest events are kept, newest discarded, and a count of discarded events is reported.
Hmm. That sounds like a possible security problem to me: simply generate a bunch of harmless messages to fill the buffer and then one can do the nasty stuff...
Dominik Kubla
Signature · 3 lines
ScioByte GmbH Zum Schiersteiner Grund 2 55127 Mainz (Germany) Phone: +49 700 724 629 83 Fax: +49 700 724 629 84 1024D/717F16BB A384 F5F1 F566 5716 5485 27EF 3B00 C007 717F 16BB
Quoted 8 lines · Dominik Kubla
Quoted 2 lines · Larry Kessler
2) If the buffer overruns the oldest events are kept, newest discarded, and a count of discarded events is reported.
Hmm. That sounds like a possible security problem to me: simply generate a bunch of harmless messages to fill the buffer and then one can do the nasty stuff...
I assume that you mean do the nasty stuff but never have anything in your
event log indicating that it happened. Good point, but if the buffer is sized appropriately for the incoming volume of events and the logging daemon
is reading the events out of the kernel buffer (as should normally be the case),
then you would see the events.
The reasoning behind this approach is to increase the liklihood that events
indicating "root cause" would be logged and not over-written by a flood of
secondary events. Keep in mind that only events originating in the kernel (or
kernel module) are stored in this buffer.
Quoted 8 lines · In article <[email protected]> you wrote:
I assume that you mean do the nasty stuff but never have anything in your
event log indicating that it happened. Good point, but if the buffer is sized appropriately for the incoming volume of events and the logging daemon
is reading the events out of the kernel buffer (as should normally be the case),
then you would see the events.
Well, depending on the type of events one can even think about a "halt" like it is required for audit trail overflow.
What would be nice is a policy for each type of event:
- overwrite old/new/halt
- rate limit
- buffer size
Quoted 4 lines · In article <[email protected]> you wrote:
Please be clear that this is NOT intended to replace printk and syslog, but to coexist with them and provide additional capabilities not available with printk/syslog that are highly desirable in large servers and Telecom environments (to name a few).
Thinks I could think of, which produce a large amount are iptables logs, audit messages and network debug logs like rejected packets, discarded packages due to checksum failures, route changes, interface changes, etc.
Of course it is only useful if it is not another framework because this will lead to kernel clutter. So do we want to replace netlink and printk?
Greetings
Bernd