Description of problem: Currently we get pam audit events showing the setup and opening of a non-interactive user session (cron job). What we don't have a record of is the script that was actually run. Sudo logs an event that shows what command its running. I think cronie should do teh same. An example event: type=USER_CMD msg=audit(06/09/2011 11:56:48.921:178) : user pid=16961 uid=root auid=sgrubb ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0 msg='cwd=/home/sgrubb cmd=script test terminal=pts/5 res=failed' Looks like cwd and cmd are the only fields needed. Because these are user controllable names, they have to be escaped. Code that ought be be about right is like this: char *command; int fd = audit_open(); const char *script = audit_encode_nv_string("cmd", cmd); asprintf(&command, "cwd=\"/\" %s", script); audit_log_user_command(fd, AUDIT_USER_CMD, command, NULL, result) free(script); free(command); close(fd); This assumes that there is a string "cmd" that is passed to the logging function with the full path to the script to be run.
Note that sudo runs the command with elevated privileges usually root. In the cron job case it is run with the same privileges as the user that created the crontab. Are we sure we need this auditing?
I think we would want the event logged before changing to the user ID associated with the job. Somewhere in the area that the pam stack gets executed and after setting the loginuid seems like the logical place to me. But yes, we could really use the information because there is no other good way to get at it.
But if I am running some unprivileged commands via bash there is no auditing either.
If you are running unprivileged commands using a shell while logged in, we can get TTY keystrokes.