Sandboxing entitlement for /dev/

We have a sandboxed Network Extension. Now we need to use /dev/auditpipe and this obviously doesn't work unless I turn sandboxing off. Is there a "temporary" exception entitlement for this kind of access? com.apple.security.temporary-exception.files.absolute-path.read-only and com.apple.security.temporary-exception.files.absolute-path.read-write have no effect on /dev/, apparently.

com.apple.security.temporary-exception.files.absolute-path.read-only and com.apple.security.temporary-exception.files.absolute-path.read-write have no effect on /dev, apparently.

Right. That’s explained right there in the name. These entitlements apply to files, and the things in /dev or not files but character or block devices.

Some questions:

  • Am I correct in presuming that you plan to deploy outside of the Mac App Store?

  • That means that your NE provider is a sysex not an appex, right?

  • What are you doing with auditpipe in an NE provider?

  • In my experience folks using auditpipe also tend to use Endpoint Security. Is that the case here?

  • Does your product include code other than this NE sysex?

Share and Enjoy

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

Yes, it's a Developer ID application with NE extension. We use auditpipe to detect user login/logout events and as far as I know Endpoint API doesn't help with those. We will use Endpoint Security at some moment in future, but not at the moment. Even if Endpoint can or will have support for such events we need auditpipe in any case to support older macOS versions. Turning sandboxing off is possible, even though it feels like a step back and I'd rather keep it.

We use auditpipe to detect user login/logout events and as far as I know Endpoint API doesn't help with those.

Correct. It’s a much-requested feature but, until it’s available, the otherwise-deprecated auditpipe is your best option.

The best path forward here is to imagine that you do have an ES client for this and put your auditpipe code in that client. That means:

  • If your ultimate goal is to ship your ES client as a system extension, add that ES sysex to your existing app and then run the auditpipe from there.

  • OTOH, if you plan to ship the ES client as a daemon, set that up and use it to run the auditpipe.

ES clients never run in a sandbox and thus they can access auditpipe without any problems.

Share and Enjoy

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

Sandboxing entitlement for /dev/
 
 
Q