Darwin work

[Robert Watson]

On Wed, 16 Aug 2006, R. Tyler Ballance wrote:

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

I believe that current OpenBSM tree, the mach event code for auditd isn't 
present, so you will need to look at the original Apple BSM package.  The most 
recent Apple BSM import was from Darwin 8.0 (Tiger 10.4.0, I believe).  My 
recommendation is to look at ways to break auditd.c into three different 
source files: auditd_devaudit.c (/dev/audit), auditd_mach.c (mach ports), and 
auditd.c, and try to capture as much of the common behavior in auditd.c as 
possible.  How exactly the details will shake out, I can't say -- it depends a 
bit how the control loop has to be changed to add in the Mach support.

>> 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 :-/

Doing the audit3 port is desirable in that it will update the BSM code in the 
Darwin kernel, bring in support for audit pipes, etc.  However, it is not 
necessary in order to get OpenBSM working, and a much smaller set of kernel 
changes would be quite useful (i.e., updating only the token encoding).

Robert N M Watson
Computer Laboratory
University of Cambridge