Bug 155519

From Stephen Smalley:

"Another change that will need to be highlighted is the impact
of the patch referenced below, which has already been submitted for
inclusion in a RHEL4 update by IBM (U2, I would guess?).  This patch
will require users who want to retain the process-related information
(pid, exe) for an avc message to enable syscall auditing (i.e. boot with
audit=1 or use auditctl -e 1 or appropriate auditd configuration) and
glean it from the subsequent syscall audit record with the same
timestamp/serial rather than directly from the avc message itself.  In
addition to avoiding the deadlock issue which motivated the patch, this
will also avoid improper attribution of certain permission denials (e.g.
denials upon packet receipt like tcp_recv, udp_recv, rawip_recv, and
recv_msg) to an unrelated process, which has confused people in the
past.  And it will allow people to get the comm information, which
although untrustworthy and possibly truncated, is nonetheless helpful in
debugging when scripts are invoked (to see the script name rather than
the interpreter as reported by the exe=).

http://marc.theaimsgroup.com/?l=bk-commits-head&m=111406582218985&w=2 "

(comments from Steve Grubb)

> But is it also as simple as 'service audit stop' and 'chkconfig audit
> off'?  

yes.

> Then the kernel will pass the audit messages to syslog?  

yes.

> Are any audit messages dropped or not created when auditd is not running?

Syslog is not guaranteed to catch everything - especially if using remote 
logging. Its rare that two back to back messages will be identical, but 
syslog does compression when messages are the same.

No longer a member of the documentation group, reassgning to group manager to
resolve.

Adding 'cc ecs-dev-list for tracking

Removing automation notification

No longer involved in RHEL Deployment Guide. Reassign to Don

Took over from what I thought was a fresh install.  RHEL 4 WS 64 Bit.  System 
shipped in Dec 07 or Jan 08 from Vendor, preloaded.  I was able to execute 
auditd and auditcntl but out of the box my system has not folder called audit 
in the var/logs directory.  Personally created and placed a audit.rules in 
the /etc but a audit.log file has not been auto generated, do I need to create 
a audit.log file and place it in var/logs/audit/ and expect it to populate via 
the auditd executeable?

(In reply to comment #9)
Should be able to run: service auditd start, stop, status, restart
Check /etc/auditd.conf, first line is where logs are written to. Make sure
destination file has permissions of 640 set otherwise it will not write to file.

Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.