Bug 1288653 - [RFE] Add USER_CMD audit event to cronie
Summary: [RFE] Add USER_CMD audit event to cronie
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: cronie
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Ondřej Pohořelský
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-04 21:33 UTC by Steve Grubb
Modified: 2022-06-01 09:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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