I recently upgraded a line of code in my Endpoint-Security client, to remove a deprecation warning:
for (NSString *mutePath in ignoredBinaryPaths) {
//(old) res = es_mute_path_literal(self.esClient, [mutePath UTF8String]);
res = es_mute_path(self.esClient, [mutePath UTF8String], ES_MUTE_PATH_TYPE_TARGET_LITERAL);
if (res!=ES_RETURN_SUCCESS)
os_log_error(setupLog, "Failed to white-list binary:%{public}@ error:%{errno}d", mutePath, errno);
}
However, after this change, I started receiving tons of ES event messages, for AUTH_OPEN and AUTH_CREATE and many others, from processes/executables I explicitly and successfully muted! Since ES is so performance sensitive - I got worried.
Inspecting better the new API I found incoherent documentation and even misleading and contradicting definitions.
But the ES headers say differently!!!
/**
* @brief Suppress all events matching a path.
*
* @param client The es_client_t for which the path will be muted.
* @param path The path to mute.
* @param type Describes the type of the `path` parameter.
*
* @return es_return_t A value indicating whether or not the path was successfully muted.
*
* @note Path-based muting applies to the real and potentially firmlinked path
* of a file as seen by VFS, and as available from fcntl(2) F_GETPATH.
* No special provisions are made for files with multiple ("hard") links,
* or for symbolic links.
* In particular, when using inverted target path muting to monitor a
* particular path for writing, you will need to check if the file(s) of
* interest are also reachable via additional hard links outside of the
* paths you are observing.
*
* @see es_mute_path_events
* @discussion When using the path types ES_MUTE_PATH_TYPE_TARGET_PREFIX and ES_MUTE_PATH_TYPE_TARGET_LITERAL Not all events are
* supported. Furthermore the interpretation of target path is contextual. For events with more than one target path (such as
* exchangedata) the behavior depends on the mute inversion state Under normal muting the event is suppressed only if ALL paths
* are muted When target path muting is inverted the event is selected if ANY target path is muted For example a rename will be
* suppressed if and only if both the source path and destination path are muted. Supported events are listed below. For each
* event the target path is defined as:
*
* EXEC: The file being executed
* OPEN: The file being opened
* MMAP: The file being memory mapped
* RENAME: Both the source and destination path.
* SIGNAL: The path of the process being signalled
* UNLINK: The file being unlinked
* CLOSE: The file being closed
* CREATE: The path to the file that will be created or replaced
* GET_TASK: The path of the process for which the task port is being retrieved
* LINK: Both the source and destination path
* SETATTRLIST: The file for which the attributes are being set
* SETEXTATTR: The file for which the extended attributes are being set
* SETFLAGS: The file for which flags are being set
* SETMODE: The file for which the mode is being set
* SETOWNER: The file for which the owner is being set
* WRITE: The file being written to
* READLINK: The symbolic link being resolved
* TRUNCATE: The file being truncated
* CHDIR: The new working directory
* GETATTRLIST: The file for which the attribute list is being retrieved
* STAT: The file for which the stat is being retrieved
* ACCESS: The file for which access is being tested
* CHROOT: The file which will become the new root
* UTIMES: The file for which times are being set
* CLONE: Both the source file and target path
* FCNTL: The file under file control
* GETEXTATTR The file for which extended attributes are being retrieved
* LISTEXTATTR The file for which extended attributes are being listed
* READDIR The directory for whose contents will be read
* DELETEEXTATTR The file for which extended attribues will be deleted
* DUP: The file being duplicated
* UIPC_BIND: The path to the unix socket that will be created
* UIPC_CONNECT: The file that the unix socket being connected is bound to
* EXCHANGEDATA: The path of both file1 and file2
* SETACL: The file for which ACLs are being set
* PROC_CHECK: The path of the process against which access is being checked
* SEARCHFS: The path of the volume which will be searched
* PROC_SUSPEND_RESUME: The path of the process being suspended or resumed
* GET_TASK_NAME: The path of the process for which the task name port will be retrieved
* TRACE: The path of the process that will be attached to
* REMOTE_THREAD_CREATE: The path of the process in which the new thread is created
* GET_TASK_READ: The path of the process for which the task read port will be retrieved
* GET_TASK_INSPECT: The path of the process for which the task inspect port will be retrieved
* COPYFILE: The path to the source file and the path to either the new file to be created or the existing file to be overwritten
*/
So the behavior completely changed, you can no longer specify executables (via their binary path) from which you do NOT want any events
Muting effectively became reactive, not proactive.
Why this change is not documented with the deprecation? Why no alternative is suggested? why find this only because it broke my software tool behavior and performance?
And last: For how long can I rely on the old, deprecated APIs, should I choose to revert my change instead of devising a whole new mechanism for muting un-interesting
