|Subject:||BSM on OSX in a networked environment (was Re: Rough plans for OpenBSM 1.1)|
|From:||Dan O'Donnell (odon...@rand.org)|
|Date:||Dec 8, 2008 4:39:02 pm|
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:
Todd Heberlein wrote:
Dan O'Donnell wrote: We have a problem with our test Mac OS X 10.5.x systems where audit trails are not being properly terminated. Is that a problem unique to our systems? Or is there any projection for when proper termination will work?
It is a common problem, but I think Apple is targeting Snow Leopard for a fix for this and other BSM Leopard problems.
FYI, as Robert indicated, I have moved the code needed to start up and shut down auditing out of auditd into its own library (libauditd). The main reason for this is to make sure auditing gets started as early as possible and shut down properly. The idea is to have Apple's root launchd start up and shut down auditing since it is the first process started and the last to exit.
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.)
auditd, however, will still service triggers from the kernel for the "steady state" maintenance of the audit trail files. Auditing will be enabled and disabled the "apple way" by editing the org.trustedbsd.auditd.plist file in /System/Library/LaunchDaemons.
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...?
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
_______________________________________________ trus...@FreeBSD.org mailing list http://lists.freebsd.org/mailman/listinfo/trustedbsd-audit To unsubscribe, send any mail to "trus...@FreeBSD.org"