This is an old revision of the document!
auditdistd - Audit trail files distribution daemon
About Security Event Audit
Security Event Audit is a facility to provide fine-grained, reliable and configurable logging of a variety of security-relevant system events, including logins, configuration changes, and file and network access.
About auditdistd
One of the key purposes of logging security events is postmortem analysis in case of system compromise. Currently the kernel can push audit records directly into a file or made them available through /dev/auditpipe device. Because audit logs are stored locally by the kernel, an attacker has access to them once the system is compromised, which enables him to remove trails of his activity.
The auditdistd daemon distributes audit records over the TCP/IP network from a local system to a remote system also running the auditdistd daemon. The project focuses on:
- Security. The auditdistd daemon was designed from the ground up to make use of strong sandboxing techniques, like capsicum(4) and jail(2). Entire network traffic is protected by the TLS encryption. In an event of network protocol compromise sandboxing prevents the attacker from accessing or modifying already delivered audit records, not to mention accessing any other parts of the operating system.
- Reliability. Audit records are considered delivered only after confirmation from the remote system that they are safely stored on disk.
- Low latency. The auditdistd daemon uses kqueue(2) to be quickly notified about new audit records, so it can distribute them as fast as possible. The goal here is to increase number of trusted audit records, as we cannot trust anything that is produced by the system after its compromise.
How does auditdistd work
The auditdistd, depending on the configuration can either run in sender-only mode or in receiver-only mode or in both modes.
In the receiver mode it is responsible for receiving audit records from the sender, storing them locally and confirming. It does not interpret received audit records mostly to avoid possible bugs in interpreter code and also to not reduce performance. This also allows to receive audit trail files in an unknown format and continue interrupted connection even in the middle of single audit record. Special care is taken for the receiver to not touch already received data. It can only open existing file in append-only mode if it is the most recent trail file or create new trail file if it will be newer than any other already received file.
In the sender mode auditdistd relies on auditd(8) to pass all newly created trail files to auditdistd-managed directory (/var/audit/dist/) by creating hard links. When trail file is terminated and auditd renames it, it will also rename the file in the /var/audit/dist/ directory. This behavior is enabled by adding 'dist:on' line to the /etc/security/audit_control file. Because hard links are used, both /var/audit and /var/audit/dist directories must be stored on the same file system, as hard links cannot cross mount point boundaries. This design choice allows to keep local retention policy for audit trail files totally independent from the existence of auditdistd daemon. If trail file from /var/audit/ needs to be removed, but auditdistd didn't complete sending it yet, only /var/audit/ entry will be removed and the /var/audit/dist/ entry will be left untouched. And if auditdistd managed to send entire terminated trail file, it will remove only its link from /var/audit/dist/ without touching the entry in /var/audit/ directory.