Date: Tue, 15 Aug 2006 20:13:24 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "R. Tyler Ballance" <tyler@bleepsoft.com> Cc: trustedbsd-audit@FreeBSD.org Subject: Re: Darwin work Message-ID: <20060815193600.H45647@fledge.watson.org> In-Reply-To: <8C40F149-F305-46DC-A39E-66E26C46822D@bleepsoft.com> References: <8C40F149-F305-46DC-A39E-66E26C46822D@bleepsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060815193600.H45647>