Securing Mach IPC

Todd Miller Todd.Miller at
Tue Mar 14 14:24:35 UTC 2006

On Mar 14, 2006, at 9:08 AM, Robert Watson wrote:

> As you observe, the issue is auditing Mach IPC is quite tricky.  In  
> the Mac OS X CAPP evaluation work, it was concluded that auditing  
> of individual message operations was not required, as Darwin does  
> not actually perform explicit access control checks for them (since  
> they are capabilities).  From a practical perspective, it was also  
> entirely unclear what benefit there would be to auditing message  
> send/receive operations, since they happen in vast volumes, and are  
> largely opaque to the kernel.  In a world with mandatory access  
> control, the individual send and receive operations, as controlled  
> operations, do need to be auditable, even if in practice they are  
> not audited in most configurations.

In the current SEDarwin sources (in FreeBSD p4 and OpenDarwin cvs) we
audit send and receive as well as port right (capability) transfers.   
Port right
transfer is audited on both the sender and receiver end so you can  
not only the ability to send a port right but also the receiver's  
right to receive it.
IIRC DTOS went even further and had the ability to specify that a  
task could
hold a right but not actually use it (useful for proxies).

For security-aware applications SEDarwin also supports mach message  
control at the method/service level.  For instance, a task may be  
able to
send messages to the bootstrap server but the policy may only allow the
task to lookup existent names and not register new ones.

> On the other hand, auditing and controlling the handing out of  
> ports by, say, the port name server would be both interesting and  
> useful.  The trick is finding a point where the semantic  
> information is maximized, and volume of events is minimized, and  
> the lookup of ports to reach services meets both of these  
> requirements.  While I was at McAfee, we spent some time looking at  
> actual usage patterns for the name server and port IPC, and found  
> it quite interesting.  To do this, we created a Darwin MAC  
> framework module that traced the communications, and fed the  
> results into various processing tools, including visualization  
> using graphviz.  I'm not sure the module supporting this analysis  
> was ever shipped in an SEDarwin release, but someone at SPARTA  
> might be able to dig it up.  The SEDarwin tree may also ship with  
> some command line tools for inspecting the current mach bootstrap  
> name space, and sample access control for that name space in  
> mach_init.

Yes, the current distribution contains the ipctrace module and some  
scripts for feeding
its output to graphviz.

  - todd

More information about the trustedbsd-discuss mailing list