App sandbox extension revoked on Ventura

Hi everyone,

first-time caller, long-ti... wait, no, I just got here. :)

I am relatively new to all things Apple, so apologies in advance if it takes me a few goes to properly explain things.

We have a framework, which includes an API, an XPC service, etc, and we have a device driver. We also have some sample apps that use the framework, and if they have the app sandbox capability, then we expect them to use the XPC Service instead of accessing our driver directly. This works fine on Monterey and presumably has worked fine on all previous versions of MacOS.

Something seems to have changed on Ventura, and we don't understand what.

When we build the same app on Ventura, it appears to be in the sandbox (according to the Sandbox column in Activity Monitor), but in the Console there is this line (twice):

default <time> <OurAppName> Revoking sandbox extension; key = 0

Which we suspect is linked to the fact that the app then does not use the XPC Service, and instead accesses the driver directly, much to our surprise.

Software built on developer's machines is "Automatically managed" and "Signed to Run Locally" in case that matters.

Do we need to change our code to support Ventura and onward? Or is it a bizarre bug?

Oh, I should say that I'm running the latest version of Ventura (13.6.7 as of writing) but not the latest Xcode (14.2 (14C18)) and CLI tools... can't remember how to find that version... Apple clang version 14.0.0 (clang-1400.0.29.202).

Any help would be appreciated, thanks.

Jeremy

if [the client apps] have the app sandbox capability, then we expect them to use the XPC Service instead of accessing our driver directly

How does your framework decide which path to take? That is, what code does it use to determine whether to use the XPC service or go directly?

Share and Enjoy

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

Hi Quinn, thanks for replying.

Based on the result of this call IOServiceOpen(driverObject, mach_task_self(), 0, &driverConnection): if it returns KERN_SUCCESS then access the driver directly, otherwise use XPC.

Cheers.

Jeremy

As I look into this, I'm beginning to suspect that it might not be anything to do with Ventura, and it's instead something strange about my machine. Still investigating.

it's instead something strange about my machine.

You haven’t, perchance, turned SIP off?

To check whether it’s on:

% csrutil status
System Integrity Protection status: enabled.

Share and Enjoy

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

Oh, yes I have, because we do device driver development. Device Extension (DExt) is the current incarnation, right?

And as I understand, because locally we use a signing certificate that does not have a Team ID, the driver is not notarised, so we have to turn SIP off. Everyone on my team has SIP turned off, so it's not unusual for us in that respect.

I just installed Sonoma on another volume to test it and the sandbox behaviour is the same, although the app itself is not working as expected, so I need to investigate that further too.

And as I understand, because locally we use a signing certificate that does not have a Team ID, the driver is not notarised, so we have to turn SIP off.

Each of your steps makes sense but I’m not sure I agree with your final conclusion (-:

My general recommendation is that you do day-to-day development with an Apple Development signing identity. That does have a Team ID, and can be included in a provisioning profile that authorises code signed with it to use of restricted entitlements. So, the real question is whether the entitlements you need are available to you for development?

AFAICT that should be the case. Here’s a test I ran today:

  1. Using the Certificates, Identifiers, and Profiles section of the Developer website, I created a new App ID.

  2. During that process, I enabled all the DriverKit capabilities.

    IMPORTANT These are development-only capabilities. For more on that, see Finding a Capability’s Distribution Restrictions.

  3. I then created a DriverKit provisioning profile from that App ID.

  4. I downloaded the profile and dumped its entitlement allowlist using the techniques described in TN3125 Inside Code Signing: Provisioning Profiles. Here’s what I got:

% security cms -D -i MacDriverKitTest_Dev.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    "application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.eskimo1.MacDriverKitTest"
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.eskimo1.MacDriverKitTest"
    "com.apple.developer.driverkit" => 1
    "com.apple.developer.driverkit.allow-third-party-userclients" => 1
    "com.apple.developer.driverkit.family.audio" => 1
    "com.apple.developer.driverkit.family.hid.device" => 1
    "com.apple.developer.driverkit.family.hid.eventservice" => 1
    "com.apple.developer.driverkit.family.networking" => 1
    "com.apple.developer.driverkit.family.scsicontroller" => 1
    "com.apple.developer.driverkit.family.serial" => 1
    "com.apple.developer.driverkit.transport.hid" => 1
    "com.apple.developer.driverkit.transport.usb" => [
      0 => {
        "idVendor" => "*"
      }
    ]
    "com.apple.developer.team-identifier" => "SKMME9E2Y8"
    "com.apple.security.get-task-allow" => 1
    "get-task-allow" => 1
    "keychain-access-groups" => [
      0 => "SKMME9E2Y8.*"
    ]
  }
  …
}

As you can see, most of what you need for DriverKit development is present.

Now, I don’t have a lot of day-to-day experience with DriverKit — one of my colleagues in DTS handles that technology — but the above indicates that it’s worth trying to re-enable SIP.

One thing I will not is the DriverKit entitlement story has changed over the years. When DriverKit was originally introduced, even the development capabilities were managed, that is, required Apple approval to use. When we rolled out DriverKit for iPadOS we changed that story, making the development capabilities available to all.

Share and Enjoy

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

App sandbox extension revoked on Ventura
 
 
Q