Bug 1288653

Summary: [RFE] Add USER_CMD audit event to cronie
Product: [Fedora] Fedora Reporter: Steve Grubb <sgrubb>
Component: cronieAssignee: Ondřej Pohořelský <opohorel>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: mmaslano, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Steve Grubb 2015-12-04 21:33:28 UTC
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.

Comment 1 Tomas Mraz 2016-02-23 14:40:55 UTC
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?

Comment 2 Steve Grubb 2016-02-23 15:15:35 UTC
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.

Comment 3 Tomas Mraz 2016-02-23 15:23:10 UTC
But if I am running some unprivileged commands via bash there is no auditing either.

Comment 4 Steve Grubb 2016-02-23 22:31:06 UTC
If you are running unprivileged commands using a shell while logged in, we can get TTY keystrokes.