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.
Sandboxing entitlement for /dev/
com.apple.security.temporary-exception.files.absolute-path.read-only
andcom.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"