Endpoint Security questions

hello all,


while experimenting with the Endpoint Security demo code, especially the ES_EVENT_TYPE_AUTH_EXEC and ES_EVENT_TYPE_AUTHP_OPEN, I need some questions answered.


(1) While blocking or allowing a process launch via es_respons_auth_resiult() it generated a nice "This Application ... can't be opened dialog" the es_response_flags_result() to prevent a file from being opened is not fully clear.


The flags are not documented (or I haven't found it yet). If I respond with the original event flags the file is allowed, great. If I respond for example with a 0 to mask out the 1 (I guess open for read), the file open fails with input/output error. In the old KEXT world when deniying a file open, the system responded with a "access denied" error code. Is there anything in these flags to get the same response?


(2) will the es client be able to open all files for which it receives event messages? with running as root and with SIP disabled it seems to work.

also, is the es client allowed / enabled to open additional files without any deadlock?


(3) with the proper entitlement, is the es client able to run as non-root user? can this be a lauch daemon?


Thanks

Frank Fenn

Sophos Inc.

Replies

Sorry I didn’t respond sooner. I’m still coming up to speed on this stuff myself.

(1) … The flags are not documented (or I haven't found it yet).

The best documentation for these flags is in the doc comment associated with

es_event_open_t
:
/**
 * Note: The `fflag` field represents the mask as applied by the kernel, not as represented by typical
 * open(2) `oflag` values. When responding to `ES_EVENT_TYPE_AUTH_OPEN` events using
 * es_respond_flags_result(), ensure that the same FFLAG values are used (e.g. FREAD, FWRITE instead
 * of O_RDONLY, O_RDWR, etc...).
 *
 * @see fcntl.h
 */

If I respond for example with a 0 to mask out the 1 (I guess open for read), the file open fails with input/output error.

Quite.

EPERM
would make a lot more sense, and we have a bug on file to fix that (r. 55131682).

(2) will the es client be able to open all files for which it receives event messages?

I’m still zenning on this one.

with running as root and with SIP disabled it seems to work.

Yeah, SIP disabled is one of my concerns, and another is network volumes, where it’s traditional to prevent root from having any access.

(3) with the proper entitlement, is the es client able to run as non-root user?

Right now it must run as root.

Share and Enjoy

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

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

(2) will the es client be able to open all files for which it receives event messages?

No. The ES client mechanism does not grant any special privileges to the process running the client. You’ll be able to open most files because you’re running as root, but there are some that are still blocked (for example, data vaults).

also, is the es client allowed / enabled to open additional files without any deadlock?

Yes, but you have to be careful. The ES subsystem divides events into authorisation events and notification events, for example,

ES_EVENT_TYPE_AUTH_OPEN
vs
ES_EVENT_TYPE_NOTIFY_OPEN
. The system prevents you from getting authorisation events that were generated by your own process. You will, however, see events for other ES clients, and that can result in a livelock (client A triggers client B which triggers client A and so on).

To help you avoid this, we specifically mark such messages generated by ES clients. Look at

es_message_t
>
process
>
es_process_t
>
is_es_client
. We recommend that you do little or no work in response to such messages.

Share and Enjoy

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

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