Date: Tue, 14 Mar 2006 14:08:39 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alex Barclay <alex@alexbarclay.net> Cc: trustedbsd-discuss@FreeBSD.org Subject: Re: Securing Mach IPC Message-ID: <20060314135929.R36625@fledge.watson.org> In-Reply-To: <1f81ef870603061110o62db95e1v58812bfdf0c1b3fb@mail.gmail.com> References: <1f81ef870603061110o62db95e1v58812bfdf0c1b3fb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Mar 2006, Alex Barclay wrote: > Understand that Sparta is working on securing mach IPC. But with the volume > of messages passed, are their plans to log/audit each mach IPC message. I > haven't been able to find out what if anything DTOS did in that regard. My recollection is that DTOS used the same access vector APIs for mach message and port access control as it did for all other access control, and therefor, audit events could be generated for send (and receive) operations if enabled. Mind you, I've never actually run the DTOS code so can't confirm whether or not it actually acted that way in practice. 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. 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. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060314135929.R36625>