Unsandboxed XPCService launches sandboxed child processes

Question

Created Apr ’24

Replies 4

Boosts 0

Participants 2

I have an application, it has main process and some child processes. As we want those child processes to have their own minimum sandbox privilege, not inheriting from parent process, we plan to use XPCService which uses a NSTask to launch those child processes, so those child processes can have its own sandbox privilege.

We plan to deliver the application to Mac App Store, so process mode is: the sandboxed main process builds connections to the unsandboxed XPCService, the unsandboxed XPCService launch those sandboxed child processes.

Can this process mode pass the Mac App Store rules? I see, there is a rule that all processes must be sandboxed, including XPCService. But I tested locally, the Application downloaded from Mac apple store also launches unsandboxed XPCService, like OneDrive.

image (3).png

Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from parent?

Answered by DTS Engineer in 813205022

[Hmmmm, I’m not sure why I didn’t see your response back in April, or why DevForums decided to notify me about the thread today, but I’m going to answer this just for the record.]

If the child executable [uses] sandbox_init with SBPL policy after child process is launched to enable its sandbox capacity.

Again, I don’t work for App Review, and thus can’t give you definitive answers about their policies. However, from a DTS perspective, SBPL is not documented for third-party use, so any use of it is unsupported.

Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from sandboxed parent process?

No. It’s possible to have components with different sandbox privileges in a Mac App Store app. For example, you can embed an XPC service with a different sandbox setup than your main app. However, all executables must be signed with com.apple.security.app-sandbox. So:

Executables that are launched by the system — your app, any appexes, any XPC services, and so on — start with a fresh sandbox. You can configure that sandbox with the entitlements described here.
Executables that are spawn by you must be signed with com.apple.security.app-sandbox and com.apple.security.inherit.

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

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’24

Can this process mode pass the Mac App Store rules?

I don’t work for App Review, and thus generally don’t comment on their policy, but App Review Guidelines are pretty clear on this point:

2.4.5 Apps distributed via the Mac App Store … must be appropriately sandboxed

In your case, it should be fine to use an XPC service that has a different sandbox than your main app. And on the NSTask front, child processes inherit their sandbox from their parent, so that’s fine too. The only tricky thing is that the child’s executable must be signed with the com.apple.security.app-sandbox and com.apple.security.inherit entitlements, as discussed in Embedding a command-line tool in a sandboxed app.

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

0

Answer 2

jingliu1 OP

Apr ’24

Thanks for your response.

There are two options to config per-program sandbox policies.

SBPL (Sandbox Profile Language), a low-level configuration language.
Entitlements

As you mentioned

The only tricky thing is that the child’s executable must be signed with the com.apple.security.app-sandbox and com.apple.security.inherit entitlements

If the child executable is not signed with entitlements(app-sandbox), but using sandbox_init with SBPL policy after child process is launched to enable its sandbox capacity. Can it pass Mac App Store rule? Child process is also sandboxed.

I saw some developers experience about the sandbox entitlements Cannot submit mac app because com.apple.security.app-sandbox is removed from entitlements

What's more, adding one prerequisite to my question before,

Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from sandboxed parent process? This application plans to deliver to MAS.

0

Answer 3

DTS Engineer OP

Apple

1w

Recommended

[Hmmmm, I’m not sure why I didn’t see your response back in April, or why DevForums decided to notify me about the thread today, but I’m going to answer this just for the record.]

If the child executable [uses] sandbox_init with SBPL policy after child process is launched to enable its sandbox capacity.

Again, I don’t work for App Review, and thus can’t give you definitive answers about their policies. However, from a DTS perspective, SBPL is not documented for third-party use, so any use of it is unsupported.

Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from sandboxed parent process?

No. It’s possible to have components with different sandbox privileges in a Mac App Store app. For example, you can embed an XPC service with a different sandbox setup than your main app. However, all executables must be signed with com.apple.security.app-sandbox. So:

Executables that are launched by the system — your app, any appexes, any XPC services, and so on — start with a fresh sandbox. You can configure that sandbox with the entitlements described here.
Executables that are spawn by you must be signed with com.apple.security.app-sandbox and com.apple.security.inherit.

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

1

Answer 4

jingliu1 OP

4d

Thanks so much for your explanation.

0