Archive for the ‘Common Criteria’ Category

OpenBSM auditing on Mac OS X

January 30, 2012 12 comments

Way back in 10.3.x, Apple submitted Mac OS X and Mac OS X Server to the National Information Assurance Partnership for Common Criteria certification. Common Criteria certification means that the the covered hardware and software has been tested and evaluated to make sure that it meets an established set of requirements for security and data protection. 10.3.6 and 10.3.6 Server were tested and were found to meet Evaluation Assurance Level 3 (EAL3) for Common Criteria certification.

As part of that certification effort, a new piece of software appeared from Apple: the Common Criteria Tools audit software. This software was OpenBSM, which is an open source implementation of Sun’s Basic Security Module (BSM) security audit API and file format. From 10.3.x – 10.5.x, this software needed to be installed and configured separately. As of 10.6.x and 10.7.x, it’s installed along with the OS. In fact, if you’re running 10.6.x and 10.7.x or their Server equivalents, it’s running now on your box unless you went in and turned it off. If you’re interested in learning more, see below the jump.

Read more…

Weird Active Directory / Common Criteria crash.

October 14, 2007 Leave a comment

I ran into an odd and hopefully rare issue with Active Directory-bound Xserves (I’ve seen it on both G5 XServes and Intel XServes) and Apple’s Common Criteria software. Essentially, when you turned the audit software on, Active Directory would crash. Turn it off, and Active Directory wouldn’t crash. Leave it off then, right? Sadly, if you’re in a situation where you’ve got the audit software installed, you most likely have a good reason for needing it on (in my case, it’s to satisfy security regs.) Even weirder, I had three servers (all G5 XServes) that were bound to Active Directory and were running the CC software, but didn’t have Active Directory crash.

What was the problem? Apple enterprise support chewed on it for a while and discovered that the crash was happening when the Active Directory plug-in was administering the admin group in the local NetInfo database. In other words, in the Active Directory plug-in’s Administrative tab, the Allow administration by: option was checked off. My three servers that weren’t having the crashes didn’t have that option checked, which supported the theory.

Causing crashes:

Picture 3

No crashes:

Picture 4

Update – 2-6-2008:

We tested this out later in October, and unchecking the Allow administration by: checkbox fixed the issue on all of the affected servers. Hopefully this won’t be an issue on Mac OS X Server 10.5.x. but I haven’t tested it yet.

Automatically starting a new Common Criteria audit log on a daily basis.

September 19, 2007 Leave a comment

As a follow-up to my previous post on using Apple’s Common Criteria audit software on OS X, there’s a simple way to automatically have your current audit log ended properly and a new one started on a daily basis. Put the commands below into a script and save the script in /etc/periodic/daily/ on the Mac in question (make sure to make your script executable.)

sudo /usr/sbin/audit -s

audit -s is the command to tell the audit software to stop the current log and make a new one; putting it in /etc/periodic/daily/ means that it’ll do it every morning at 3:30 AM.

Clearing old Common Criteria audit logs.

September 13, 2007 Leave a comment

One of the software packages that Apple makes available on its website is Apple’s Common Criteria Tools. This package is based off of Sun Microsystem’s Basic Security Module (BSM) auditing software and is a tool for creating an extremely detailed audit trail for all processes on the system. The level of auditing produced is at the level required by systems attempting to achieve the DoD “C2” level certification. The good side is that, by default, you get extensive information on *every* process and action that your system has running. The down side is that we’re obviously talking about enormous amounts of data being logged here, with large 100MB+ log files being common. I’ve found that BSM can generate truly enormous files, where log files can grow into gigabyte sizes, when you’re using them in conjunction with Retrospect. (To clarify, I’m getting the enormous gig-sized logs on servers where I’m running Retrospect to backup other machines; just having the Retrospect network backup client on your system will not cause BSM’s log files to get larger than normal.)

Since I need to run the auditing tools, but at the same time I need to conserve space on the servers, I wrote this script (based off another person’s script I found online; sadly, I can’t find the link to the original script) to clear logs older than 10 days old and put the script into /etc/periodic/daily, so that it would kick off with the daily maintenance scripts.

# Delete old log files
find $AUDIT_DIR/* -type f -mtime +$AUDIT_EXPIRE -exec rm -f {} \;

You can set the script to keep your audit logs longer by changing the value of the AUDIT_EXPIRE variable.

%d bloggers like this: