[NOTE - leave bug #149551 as a blocked by this bug, for tracking purposes] ## Description of document bug or feature request: If auditd is running, and this may be in U1 (unknown to author at this writing), audit messages _including_ AVC messages are routed by the kernel into /var/log/audit/audit.log when auditd is alive. If auditd is uninstalled or disabled, audit messages are sent to syslog, which puts them in /var/log/messages and dmesg. This may be a major issue if auditd is included in an update to RHEL 4 _and_ is set to run by default. Keep this bugzilla until that is resolved, and if necessary highlight the changes in the guide. ## Version-Release number ## This is found on the legalnotice.html page and on this page with ## instructions: rhel-selg(EN)-4-HTML-RHI (2005-02-15-T16:20) ## Additional information?
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.