Changing the thread subject since this is different from the original subject line...

On 12/5/08 12:45 PM, "Stacey Son" <ss...@freebsd.org> wrote:

We have been trying to set up a system whereby the audit logs are written to an NFS mounted remote machine. Since auditd starts before networking, it seems we must change the sequence. We tried changing the launch sequence so as to allow networking to start before auditd, but that didn't work. (rc script? launchd modification?)

We've fallen back to a shell script that will do the following, after the startup and launch sequence is complete: 1) stop the audit daemon 2) change the location of the target location of audit trail file in security/audit_control from localhost:/var/audit to logserver:/var/audit/hostname 3) restart the audit daemon

On shutdown initiation another script will then: 4) Shutdown auditd 5) Restore the location of the audit trail file to localhost:/var/audit 6) restart auditd 7) allow shutdown to continue to completion

This leaves two small orphan files on the local machine, but the file with most of the information is on the remote server. We may try to go back and get those orphaned files with scp on next startup, but will work on that problem when we get to it.

It's also a bit of a nuisance because machines in different geographic locations will talk to different servers and thus will have to have the script modified for the logserver in that location.

It seems to me there ought be a more elegant way using launchd to keep the audit trail file complete and write it to a remote location, but I don't have the skill set in that space. Am open to any advice or suggestions.

We are forwarding the syslog files (OSX, linux, Solaris) to a remote log server by modifying /etc/hosts, and are forwarding the Solaris BSM files to another audit server, but forwarding the OSX audit trail file is more challenging and is not yet solved.

There is some hope that we will eventually be able to capture all the syslog files and audit files - including the OSX audit trail file - with a third party application that is designed to accumulate and index that info. When that happens we will no longer need any of the scripting kludge described above.

(And of course all the above is 10.4 or 10.3, but not 10.5 since it doesn't yet work sufficiently well to satisfy our auditing regulatory mandate.)

Currently the Apple method of enabling or disabling auditing is by toggling the AUDIT=-OFF- line entry in /etc/hostconfig. Apple has warned us (generally) that this file is going away. I haven't seen Snow Leopard so I don't know if it is gone in that upcoming version of the OS, but I assume it will be and then perhaps we will use the method you describe...?

Dan