Reputation: 1202
I am integrating EndpointSecurity Framework and observing ES_EVENT_TYPE_AUTH_EXEC
event.
I able to see the command arguments, but I am not able to read the command input.
Assuming that the command is as follow:
thirdPartyApp do something < ~/Desktop/file.txt
My code is: (msg is a value of type es_event_exec_t *
)
for (int i = 0; i < es_exec_arg_count(&msg->event.exec); i++) {
es_string_token_t arg = es_exec_arg(&msg->event.exec, i);
print("arg: %s",arg.data);
}
The code output is only:
thirdPartyApp do something , without < ~/Desktop/file.txt
The thing is, < ~/Desktop/file.txt is not an argument, its a redirect as described here
Waiting to here from you
Upvotes: 0
Views: 239
Reputation: 7897
Redirects work by the shell open(2)ing the files you redirected and dup(2)ing them onto 0,1,2 (depending on redirect) before fork(2)ing or posix_spawn(2)ing, and allowing the child (spawned command). That means that EPS will not be able to see them as es_exec_args - because (as you correctly say) they're not arguments.
If you use
const es_fd_t * _Nonnull
es_exec_fd(const es_event_exec_t * _Nonnull event, uint32_t index);
you should be able to get back an es_fd_t - however the only relevant field will be the fdtype:
typedef struct {
int32_t fd;
uint32_t fdtype;
union {
struct {
uint64_t pipe_id;
} pipe;
};
} es_fd_t;
A better option is to thus leave the comfort of EPS and use proc_info(2) (via libproc.h) which can get you the full FD information for any process and fd (much like supraudit from http://newosxbook.com/tools/supraudit.html does).
Note, that STILL won't get you the input itself. That input is consumed by the process using read(2) (and output using write(2), of course), and neither EPS nor BSM (auditing) offers hooks for that.
Upvotes: 1