Darwin work

R. Tyler Ballance tyler at bleepsoft.com
Wed Aug 16 11:15:10 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 15, 2006, at 2:13 PM, Robert Watson wrote:

> 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.

That said, should I be using Apple's own bsm module as a reference  
for writing the mach ports specific code, or is there existing code  
for receiving the audit events from Xnu already somewhere lurking  
around within OpenBSM? (I've been glancing over Apple's bsm code,  
which is under a 3-clause license, so I don't think it would be a  
probably for me to base my code off of it).

> 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.

The full audit3 port would be something, IMHO, that would be best  
done with a reasonable amount of conjunction with the SEDarwin  
project, although it seems that they are aiming more at bringing the  
MAC framework and some of the security enhancements that SELinux  
brought to the table, so I'm not sure if an audit3 port necessarily  
fits within their project goals.

That said, I suppose it's time to finally reboot this bloody machine  
to enable auditing from the Common Criteria Tools :-/


Cheers,

- -R. Tyler Ballance
Lead Developer, bleep. LLC
http://www.bleepsoft.com





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4v4vqO6nEJfroRsRApyYAJ4mov9M9Q9Se2Ya6cTqEERpfqB8JQCeISNl
tb49LK0k58/VrTIgkf+v5gw=
=LQlf
-----END PGP SIGNATURE-----


More information about the trustedbsd-audit mailing list