AUDITD-PLUGINS(5)

🎀 AUDITD-PLUGINS 🎀

so this is auditd-plugins(5), from the System Administration Utilities manual, and honestly it's the glow-up guide for anyone who wants their program to be a realtime event receiver. hi bestie 💖 pull up a chair.

---

✨ NAME ✨

auditd-plugins — realtime event receivers 🫶

---

🌸 DESCRIPTION 🌸

okay so auditd can multiplex audit events in realtime, no cap. it takes those audit events and distributes them out to child programs that wanna analyze events in realtime. and here's the cute part: when the audit daemon catches a SIGTERM or a SIGHUP, it passes that signal straight down to its child processes so they can reload their configuration or terminate. it's giving ✨good parenting✨.

the child programs install a configuration file in a plugins directory, which defaults to /etc/audit/plugins.d. if the admin felt like putting plugins somewhere else, that can be controlled by the plugin_dir config option in auditd.conf. but heads up: auditd will install its own plugins in the default location regardless. periodt.

the plugin directory gets scanned, and every plugin that is active will be started. if a plugin has a problem and exits, it'll be started a maximum of max_restarts times — that number lives in auditd.conf, go look at it.

now, config files have RULES:

• they must be regular files
• they must not begin with a . character
• they must contain at most one . character
• they must have a .conf suffix

files that don't meet these criteria get skipped, sorry babe 🙈. config file options are given one per line, with an equal sign between the keyword and its value. the available options are:

• active — the options for this are yes or no.
• path — the absolute path to the plugin executable. for internal plugins, this would be the name of the plugin instead.
• type — tells the dispatcher how the plugin wants to be run. there is only one valid option, always , which means the plugin is external and should always be run. the default is always since there are no more builtin plugins.
• args — lets you pass arguments to the child program. generally plugins don't take arguments and have their own config file that tells them how they should be configured. at the moment, there is a limit of 2 args.
• format — valid options are binary and string. binary passes the data exactly as the audit event dispatcher gets it from the audit daemon. string tells the dispatcher to completely change the event into a string suitable for parsing with the audit parsing library. the default value is string.

---

💀 NOTE 💀

auditd has an internal queue to hold events for plugins (see the q_depth setting in auditd.conf). plugins have to watch for and dequeue events as fast as possible, and queue them internally if they can't be immediately processed. if a plugin is not able to dequeue records, the auditd internal queue will get filled. 💅

at any time, as root, you can run the following to check auditd's metrics:

auditctl --signal cont ; sleep 1 ; cat /run/audit/auditd.state

plugins using libauplugin can retrieve their own queue metrics with auplugin_queue_depth, auplugin_queue_max_depth, and auplugin_queue_overflow. the auplugin_register_stats_callback function allows reporting these values from a signal handler. iykyk 🧚

if auditd's internal queue fills, it cannot dequeue any events from the kernel backlog. and if the kernel's backlog fills, it looks at the value of backlog_wait_time to delay all processes that generate an event, to see if there is eventually room to add the event. you will likely notice this as slowing down various processes on the machine. the kernel's audit subsystem can be checked by running:

auditctl -s

when tuning the audit system's performance, you'd want to check both kernel and auditd metrics and adjust accordingly. balance, bestie, balance 🌈

---

👑 NOTES FOR DEVELOPERS 👑

when the audit daemon starts your plugin, you will be running as root. if you do not need root privileges, you should change uid/gid to lower your chances of being a target for exploit. if you need to retain capabilities, using libcap-ng is the simplest way. do it, bestie, protect yourself 🫶

your environment is not going to be clean. you are inheriting many attributes from auditd itself. you will need to adjust your signal mask, sigaction, umask, and environmental variables. look at the auditd man page to see which signals auditd used. plugins are expected to handle SIGTERM and SIGHUP. you will also inherit the resource limits of auditd. note that some of these resource limits, such as maximum number of open descriptors, are controlled by systemd. you also inherit auditd's nice value — you might want to adjust that to be sure to keep up with incoming audit events. 💅

auditd will send events to the plugin on its stdin. the plugin has to keep this descriptor empty so that events don't back up. if you do significant processing of each event, you should add an internal queue to your design in order to keep events flowing. the auparse_feed function is the preferred way to examine whole events if you need to analyze the contents of the events. that's the whole vibe fr fr. ⭐

---

🍓 FILES 🍓

• /etc/auditd/auditd.conf
• /etc/audit/plugins.d

---

🦋 SEE ALSO 🦋

• auditd.conf(5)
• auditd(8)
• execve(2)
• auparse_feed(3)

---

💜 AUTHOR 💜

Steve Grubb

---

and that's the whole page, bestie!! this came out of the Red Hat fam, dated Jan 2024, and it's the AUDITD-PLUGINS(5) page itself — so go forth, build your plugin, handle your signals, and don't let that queue fill up. slay 💖✨🎀