Best practices for the system extension (Endpoint Security)

Before the system extension was introduced a common approach was - using a daemon process together with a kernel extension (kauth/nke etc). But now there are more options:

1) we can call the new API(Endpoint Security) directly from the daemon process without any system extension at all.

2) we can implement in the system extension only event subscription while doing actual processing in the daemon process.

3) implement all daemon code in the system extension.


It looks like all this approaches are correct. What are the best practices for the system extension? I am especially interested in cases 2 and 3. Are there any restrictions for the third approach (file/sockets access etc)? Do we need to implement the system extension as small/smart as possible while implementing actual processing into the separate process?

Replies

My preferred option is to do all of this work inside your sysex. That results in the fewest moving parts, which is likely to yield better performance and reliability. Also, there are some unique advantages to using a sysex.

Are there any restrictions for the third approach (file/sockets access etc)?

Your ES sysex will require Full Disk Access, but that’s also true if you use a

launchd
daemon.

Beyond that, I can’t think of any other major restrictions. There are things that your sysex won’t be able to do — like look inside a Data Vault — but, again, that’s also true for a daemon.

Do we need to implement the system extension as small/smart as possible while implementing actual processing into the separate process?

You can do but that’s not the approach I’d take. An ES sysex is already triggering one IPC hop (kernel to sysex) and adding another hop just complicates things. Specifically, you need to make sure that your IPC is fast, that your other process has appropriate QoS, and so on. This all adds unnecessary complexity IMO.

Oh, one other thing: A sysex makes it easy to package your product whereas you have to jump through some extra hoops if you use a

launchd
daemon.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you.

That was very helpful

Does #1 ("call the new API(Endpoint Security) directly from the daemon process without any system extension at all") actually work with the "com.apple.developer.endpoint-security.client" entitlement? Following the example here, with SIP turned on, I can't get this to work.

Does #1 ("call the new API(Endpoint Security) directly from the daemon process without any system extension at all") actually work with the "com.apple.developer.endpoint-security.client" entitlement?

I’ve not tried it myself but I figure that, if it wasn’t working, I would’ve heard lots of complaints. What are the symptoms of the failure?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

If I take your DaemonInAppsClothing sample, and add a call to es_new_client and all the appropriate entitlements, I get a ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED error.


Having said that, the solution given in another post of granting "Full Disk Access" to my app seems to work. Is this by design? Is there any way to grant access programmatically when we are installing our security app? How is this intended to work in the real world?


Edit: now that I've thought about it a little more, if "Full Disk Access" isn't already implied by the "endpoint-security.client" entitlement, which we had to obtain from Apple, then what's the point of that entitlement?

Is this by design?

Yes.

Is there any way to grant access programmatically when we are installing our security app?

No.

How is this intended to work in the real world?

Given the privacy risk associated with EndpointSecurity clients, standard users have doubly opt in (that is, enable the sysex and enable Full Disk Access).

My experience is that a significant target market for ES clients is managed Macs, where the site admin can opt in without user intervention using the various configuration profile payloads.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

<<standard users have doubly opt in>>


Why? What is the point of "yes allow this, yes really allow this"? It seems to me the "endpoint-security.client" entitlement would IMPLY "Full Disk Access" anyway, as I said above. At the very least there should be a separate entitlement, because trying to explain the steps for a user to grant "Full Disk Access" to a daemon "app" is frankly embarassing.