App sandbox extension revoked on Ventura

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"