4:11 p.m.
Hi , I am following the sample code at
-https://github.com/linux-audit/audit-userspace/blob/4939b8541322cbf3a53affc28e71ce53d92f121f/contrib/plugin/audisp-example.c
to write my own plugin. The number of events that will be generated on my system will be
huge as I want to monitor a lot of root activities. So in my plugin I have created 2
threads- reader and processor. Reader is reading off the STDIN and putting the
"msg" (MAX_AUDIT_MESSAGE_LENGTH) into a list. Processor is popping each
"msg" off the list and calling "auparse_feed" for each msg . Finally
in handle_event , I am looping through the records of each event and calling my own
logging API to log it on the remote server. I am seeing a lot (in 1000's) of
repetitive audit records on my remote server (exact same records, same timestamp and same
ID value) , though I do not see the same in local audit.log file.
Not sure what's going on wrong with my logic
4:13 p.m.
I think some sort of a loop which is causing the duplication of records on my remote
server. Any suggestions on how to debug this ?
4:44 p.m.
Hello,
On Monday, May 13, 2024 5:11:50 PM EDT nupurdeora(a)gmail.com wrote:
Hi , I am following the sample code at
-https://github.com/linux-audit/audit-userspace/blob/4939b8541322cbf3a53af
fc28e71ce53d92f121f/contrib/plugin/audisp-example.c to write my own plugin.
The number of events that will be generated on my system will be huge as I
want to monitor a lot of root activities. So in my plugin I have created 2
threads- reader and processor.
This sounds good so far. And do you have synchronization around enqueuing and
dequeuing?
Reader is reading off the STDIN and putting the "msg"
(MAX_AUDIT_MESSAGE_LENGTH) into a list.
The records will come in one at a time and will be shorter than
MAX_AUDIT_MESSAGE_LENGTH. Also, a common mistake is using select/poll on
stdin and then using fgets to read it. It will cause strange errors to mix fd
and FILE * operations. To straighten this out for my own use, I create the
equivalent of fgets except it takes a fd.
https://github.com/linux-audit/audit-userspace/blob/master/common/audit-f...
I've thought about exposing that as an API since anyone doing a plugin has a
need for this.
Processor is popping
each "msg" off the list and calling "auparse_feed" for each msg .
Finally
in handle_event , I am looping through the records of each event and
calling my own logging API to log it on the remote server.
OK.
I am seeing a lot (in 1000's) of repetitive audit records on my
remote
server (exact same records, same timestamp and same ID value) , though I do
not see the same in local audit.log file.
Not sure what's going on wrong with my logic
Since the plugin reads from stdin, you can cat a file into the plugin:
cat audit.log | ./plugin
Just save a few events in it using "ausearch --raw" to preserve the events as
they are.
I would make a debug mode for the plugin to write to stdout and then see if
what goes in comes out. I'd also compile it with the thread sanitizer and see
if that shows anything.
-Steve
12:58 p.m.
Another question is , Is there a metric on the number of events that the sample
audisp-example.c can handle without queuing ?
Also how do I control or link the start & stop of the plugin when I do something like
"service auditd restart" ?
1:25 p.m.
On Tuesday, May 14, 2024 1:58:35 PM EDT nupurdeora(a)gmail.com wrote:
Another question is , Is there a metric on the number of events that
the
sample audisp-example.c can handle without queuing ?
It depends entirely on how much processing you are doing. There are syslog
and af_unix plugins that do very little processing and can keep up. But if
you do networking it can take time for the other end to ACK that it received
it.
The audit daemon also has an internal queue between the logger and the
realtime interface. This queue is shared by all plugins from the stand point
that the current event is not retired until all plugins have seen it. So, if
your plugin is slow, it affects the speed of the other plugins.
So, it is important to dequeue inbound events from stdin ASAP. If you are
slow, then it may cause auditd's internal queue to fill. When that happens, it
can't dequeue anything from the kernel and it starts backing up. Depended on
what you set for the the kernel failure action, you could panic the kernel if
it fills up.
The safest thing is to make 2 threads, one dequeing and the other processing.
This way events keep flowing and don't backup somewhere.
Also how do I control or link the start & stop of the plugin when
I do
something like "service auditd restart" ?
When you do a restart, auditd receives a SIGTERM. It in turn sends SIGTERM to
all child processes. The example plugin has a SIGTERM handler and causes the
plugin to exit. When you get SIGTERM, you should do whatever you need to do
to cleanup and exit asap. Systemd can intervene with SIGKILL if a daemon
hasn't exited within a "reasonable" time. We don't want that.
-Steve
221
days inactive
222
days old
linux-audit@lists.linux-audit.osci.io
4 comments
2 participants
participants (2)
-
nupurdeora＠gmail.com -
Steve Grubb