Bug 1288653 - [RFE] Add USER_CMD audit event to cronie
[RFE] Add USER_CMD audit event to cronie
Status: NEW
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-04 16:33 EST by Steve Grubb
Modified: 2016-02-23 17:31 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Grubb 2015-12-04 16:33:28 EST
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)

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 09:40:55 EST
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 10:15:35 EST
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 10:23:10 EST
But if I am running some unprivileged commands via bash there is no auditing either.
Comment 4 Steve Grubb 2016-02-23 17:31:06 EST
If you are running unprivileged commands using a shell while logged in, we can get TTY keystrokes.

Note You need to log in before you can comment on or make changes to this bug.