Should embedded XPCServices validate incoming connections?

Yes. To understand how this works you need some background on how Mach bootstrap namespaces work. A good place to start here is the old-but-still-kinda-useful Technote 2083 Daemons and Agents. And some of the background in XPC and App-to-App Communication might be helpful.

macOS maintains a hierarchy of Mach bootstrap namespaces. The XPC services embedded within your app are registered in a namespace that’s unique to your app [1]. No other process runs in that exact namespace, not even a child process that you spawn, and thus other process can’t connect to the XPC service.

But, honestly, if you’re trying to satisfy your security auditors, I recommend that you not take my word for it (-: Build some test projects to confirm my assertions. And if you’re feeling especially enthusiastic, add them to your test suite.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] There are a bunch of subtle details I’m glossing over here, and this is one of the places where the age of TN2083 is telling )-:

@DTS Engineer I have a follow up question though. I understand that the bootstrap namespace is private to to application so I can't connect its XPC service by name if I don't have access to that namespace.

But what If I know the mach port? Let's say I'll be lucky and guess the port :-) ...or use launchctl to tell me:

$ launchctl print pid/12345/com.my.test.service
...
	endpoints = {
		"com.my.test.service" = {
			port = 0xeaf13
			active = 1
			managed = 1
			reset = 0
			hide = 0
			watching = 0
		}
	}
...

In that case I would I be able to use msg_send() to send messages directly and eventually replicating what XPC does or is there any other level of protection (e.g. what comes to mind is that launchd can check the audit session or something)?

But what If I know the mach port?

Mach is a capability-based system (as defined here). You can only work with ports that you’ve been granted access to via the system. That’s why the bootstrap service is so important.

I touch on this in XPC and App-to-App Communication, and you should read that first. However, I want to expand on it a little here.

When you work with Mach ports in user space, you typically use a value of type mach_port_t. However, this is not a Mach port. Mach ports exist within the kernel and you don’t have direct access to them. Rather, you work with a Mach port name [1]. That’s an integer that denotes an entry in your task’s Mach port namespace. That namespace is managed by the kernel. The Mach port names are pretty much equivalent to a traditional Unix file descriptor.

Within the kernel, each Mach port namespace entry points to a Mach port and tracks the rights that the task’s Mach port name holds for that port.

So, you can’t access a Mach port by ‘guessing’ its port name, in the same way you can’t access a random file by ‘guessing’ a file descriptor. For you to have access to the port the kernel must have inserted an entry for that port into your task’s Mach port namespace. Which is exactly what the bootstrap service does when you successfully look up a name.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Some APIs actually use the mach_port_name_t type alias, but that’s not consistent. Mach is a very confusing API for historical reasons. I can only assume that the original authors didn’t understand how vital a glossary is when describing your API (-:

For you to have access to the port the kernel must have inserted an entry for that port into your task’s Mach port namespace. Which is exactly what the bootstrap service does when you successfully look up a name.

Ah now I get it! I got stuck with deceiving idea that bootstrap service is kind of "DNS" for ports, but was not thinking for a minute how the port name actually gets into the process's port namespace. Now it makes much more sense.

Thank you for connecting the dots for my dumb brain! :-)