> 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). -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
