How much practical benefit is there to XPC-based privilege separation?

"Privilege separation" is one of the "two main reasons to use XPC services" given by https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html

With traditional applications, if an application becomes compromised through a buffer overflow or other security vulnerability, the attacker gains the ability to do anything that the user can do. To mitigate this risk, Mac OS X provides sandboxing—limiting what types of operations a process can perform. […] Each XPC service has its own sandbox, so XPC services can make it easier to implement proper privilege separation.

The idea (iiuc) being that if the main process is compromised, the spicier operations have been separated out to a separate process space, and this improves the security of the system.

But if the main process is compromised, and that main process is trusted by the more-privileged XPC service, is not the system still compromised in practice? That is rather than the exploit being:

  1. exploit some vulnerability
  2. gain arbitrary code execution
  3. do something naughty

isn't the same still possible with just one extra step:

  1. exploit vulnerability
  2. arbitrary execution
  3. ask the XPC service nicely…
  4. …to do something naughty?

Ahhhhh this is one of those brain loops I go on every few years. Right after posting I re-remembered at least part of the potential answer when I go down this route:

There is at least one (potential) improvement in the XPC case, because while the XPC service might be running with elevated privileges/entitlements it might not expose full access to those.

I.e. imagine an XPC service that gets installed as a system daemon to idk… delete another user's account, say. So it exposes an interface with one method, which takes the unfortunate user's name as a string and does the deed via its own root-esque privileges.

Now, if the main app is compromised the damage is at least somewhat contained. Barring a further vulnerability in the XPC daemon it can only delete user accounts. Not that that's great, but at least it can't also delete applications (barring path traversal bugs…) or reconfigure printers or install its own persistent privileged daemons….

  1. exploit vulnerability in main process
  2. arbitrary execution there
  3. pick shenanigans only from a limited menu of XPC service offerings

Is this the main/only benefit, or am I missing others?

I was about to respond in a similar fashion.

An exploit is typically considered a binary operation. The app is either secure or exploited. XPC Services make that a floating point. The app can be partially exploited, on either the main or the XPC side(s). That both limits the risk and increases the cost of the exploit.

However, then you mentioned daemons. That's something completely different. XPC is many different things. It is a communication protocol that can be used by both XPC services and daemons. But XPC services are not the same thing as daemons.

XPC services are easy to use and deploy. They give you some flexibility with sandboxing. But there's nothing easy about daemons, including The XPC communication.

How much practical benefit is there to XPC-based privilege separation?
 
 
Q