freebsd-security folk may also be interested in this forthcoming addition to OpenBSM from Pawel. I plan to cut a new OpenBSM alpha rev with auditdistd in the next couple of days. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Wed, 21 Nov 2012 00:42:45 +0100 From: Pawel Jakub Dawidek <[email protected]> To: [email protected] Subject: OpenBSM new addition: auditdistd. Hi. In the new release of OpenBSM one of the major additions would be the auditdistd daemon. The work was sponsored by the FreeBSD Foundation. Thank you! Auditdistd is used to reliably and securely transfer local audit trail files over the network to separate machine, so that in case of successful attack on the local machine, an attack is unable to tamper with already distributed audit records. The auditdistd can operate in two modes: as a sender and as a receiver. In the first mode (the sender), auditdistd is reponsible for sending audit events gathered locally to remote auditdistd that operates in the receiver mode. The auditdistd in the receiver mode is responsible for receiving and storing audit trail files locally. On the receiver side there is no need for audit subsystem to be turned on. Auditdistd for speed, reliability and also security doesn't interpret audit trail files. Any file could be send and receive. The receiver places the files in a directory dedicated to the sending system. Sending side has no control over the place where received trail files are stored. The receiver also accepts only new audit events. It works in append-only mode. Previously received trail files and audit records stored in most recent trail file cannot be modified by the sender. These restrictions allow to assume that even if sender side was compromised in the given point in time, all previous audit records from this host can be trusted. Auditdistd uses sandboxing (including Capsicum's capability mode if availble), which is especially important for the receiver mode. In the current implementation after breaking through auditdistd protocol into the receiver process, an attacker has no access to audit trail files from other senders. This may be improved to use Capsicum's capabilities and only provide append-only file descriptors to the receiver process. Unfortunately with the current Capsicum implementation it is not possible to limit file descriptor to append-only writes. As part of another projected I changed that, so it should be available in the future. The auditdistd is as autonomous as possible, but sometimes auditd help is needed. Audit trail files are created by auditd in response to a request from the kernel audit subsystem. Auditd creates a file in /var/audit/ directory and of <timestamp>.not_terminated format. It also creates symlink 'current' to this file. Auditdistd needs hardlink to audit trail file in /var/audit/dist/ directory. It could create the hardlink by itself by monitoring changes to the /var/audit/ directory, but it might not be reliable. It might be possible that new audit trail file is created, terminated and removed before auditdistd had a chance to notice the file. This way we would lose some audit events. That's why more reliable option is to modify auditd to create hardlink in the /var/audit/dist/ directory the same way it creates symlink to current audit trail file. Similarly, auditd might be responsible for renaming ..not_terminated files in /var/audit/dist/ directory to final name after termination for the same reason - auditdistd might not see the final name before trail expires and is removed from /var/audit/. Having a hardlink to trail file in /var/audit/dist/ eliminates the need for communication between auditd and auditdistd daemons. Each of them can remove their links whenever they want. If auditd decides that trail file expired and removes it from /var/audit/ directory, it doesn't affect link in /var/audit/dist/ directory that might not be sent yet by the auditdistd to the receiver side. And vice-versa - if auditdistd successfully sends trail file to the receiver side before it expires locally, it will just remove its link from /var/audit/dist/ without affecting /var/audit/ link. Configuration is pretty trivial. On the sender side where we gather audit records we have to add the following line to the /etc/security/audit_control file: dist:on And create /etc/security/auditdistd.conf file, eg.: sender { host "bigbrother.freebsd.org" { remote "tls://10.0.0.5" fingerprint "SHA256=8F:0A:FC:8A:3D:09:80:AF:D9:AA:38:CC:8A:86:53:E6:8F:B6:1C:55:30:14:D7:F9:AA:8B:3E:73:CD:F5:76:2B" password "YjwbK69H5cEBlhcT+eJpJgJTFn5B2SrG" } } Fingerprint from receiver's public key can be obtained by running: openssl x509 -in /etc/security/auditdistd.cert.pem -noout -fingerprint -sha256 | awk -F '[ =]' '{printf("%s=%s\n", $1, $3)}' On the receiver side we need to put certificate and private key into the following files: /etc/security/auditdistd.cert.pem /etc/security/auditdistd.key.pem And create the following /etc/security/auditdistd.conf: receiver { host "freefall.freebsd.org" { remote "tls://10.0.0.2" password "YjwbK69H5cEBlhcT+eJpJgJTFn5B2SrG" } } -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"