Date: Tue, 14 Mar 2006 09:24:28 -0500 From: Todd Miller <Todd.Miller@sparta.com> To: Robert Watson <rwatson@FreeBSD.org>, Alex Barclay <alex@alexbarclay.net> Cc: trustedbsd-discuss@FreeBSD.org Subject: Re: Securing Mach IPC Message-ID: <20E9DC0B-549E-41DA-9025-F2BDC1B7EA96@sparta.com> In-Reply-To: <20060314135929.R36625@fledge.watson.org> References: <1f81ef870603061110o62db95e1v58812bfdf0c1b3fb@mail.gmail.com> <20060314135929.R36625@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 specify 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 access 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20E9DC0B-549E-41DA-9025-F2BDC1B7EA96>