What I'm getting is that in addition to kernel-generated local
events
the auditd would also receive signals as well as tcp-based events from
other sources. Would this be the way of implementing multi-source audit
aggregation or is it something different?
The net result is to aggregate audit logs from many systems onto one
central audit server. Remote audit messages have the new "node=" tag
on them so you know where they came from.
I.e. you configure audisp-remote.conf like this:
remote_server = 10.2.3.4
port = 1237
And the central server (10.2.3.4 in this example) like this:
tcp_listen_port = 1237
And then the client sends all audit messages to the server, where
they're logged to disk.
This is similar to centralized syslog logging.
The event loop change I linked to is a neccessary design change
prerequisite to this one, since the listener adds (potentially) many
descriptors which will need to be serviced. The loop now services
four types of events: local signals, local netlink, the listen socket
(for new connections), and client sockets (for incoming audit
messages).