Darwin work

[Robert Watson]

On Tue, 15 Aug 2006, R. Tyler Ballance wrote:

> I suppose it's worth mentioning here, after talking to rwatson@ a bit about 
> what work needs to be done on openbsm and the audit3 code. I'll be initially 
> starting with the openbsm code of course, but I'll be toying with it more 
> academically in my spurious free time, so I'd be more than happy to accept 
> any help ;)
>
> FWIW, I also uploaded notes from rwatson's conversation with me: 
> http://tyler.geekisp.com/doc/openbsm_notes.txt
>
> The best plan of attack that we (ok, more him than me) came up with was 
> making the Darwin openbsm code operate in the same manner (the /dev/audit 
> pseudo-device) as the FreeBSD and Linux code, and then work from there. I'm 
> branching the mainline openbsm and audit3 code into my user directory in 
> perforce right now, and I'll be sending the autoconf stub patches there for 
> testing, you'll be able to get the code from: //depot/user/tyler/openbsm/... 
> and //depot/user/tyler/audit3/...

Bringing the audit3 kernel code to Mac OS X is a fairly serious undertaking, 
as it requires basically replacing the older kernel audit framework in Darwin 
with the newere one from FreeBSD.  It's certainly not impossible -- it's been 
demonstrated on a number of occasions that porting FreeBSD code to Darwin can 
be done, especially if one avoids areas that have diverged significantly.

The first step is to get OpenBSM fully working on Darwin.  We've been 
compiling and testing most OpenBSM components at least minimally on Mac OS X 
and Linux during development.  This means that the configuration files, 
library, and user space BSM tools, such as auditreduce and praudit, should 
pretty much "just work" on both platforms.  It's components like auditd and 
auditfilterd, which interact with the kernel as a source of audit events, 
where the work becomes more tricky.

As I mentioned to you in IRC, and appears in the above transcript, the first 
major issue is teaching the new OpenBSM auditd about the Darwin trigger model, 
which is based on Mach port IPC, rather than the pseudo-device /dev/audit as 
found on FreeBSD.  At least, if you want OpenBSM to run with an unmodified 
kernel.  If you don't mind a modified XNU kernel, porting just 
src/sys/security/audit/audit_trigger.c from FreeBSD to Darwin is probably 
pretty straight forward.  Getting OpenBSM working properly on Darwin would be 
very useful indeed, even without doing all the kernel work.

After the OpenBSM pieces are fully working on Darwin, it's desirable to 
substitute the new OpenBSM bsm/ include files for the existing Darwin ones. 
That will, among other things, teach the Darwin kernel to generate records 
using the new OpenBSM header version and event numbers, rather than ones that 
may (in the future) conflict with Solaris events.  Finally, without doing a 
full audit3 port, a desirable change to port to Darwin is the token generation 
changes, which fix some bugs and add endian-independence (writing out in 
network byte order rather than native byte order).

Doing a full port requires basically porting over src/sys/security/audit from 
the FreeBSD tree to Darwin, and also src/sys/bsm, replacing the current files, 
which are largely in xnu/bsd/kern and xnu/bsd/bsm.

Robert N M Watson
Computer Laboratory
University of Cambridge