Red Hat Bugzilla – Bug 155519
highlight changes in audit message logging when auditd is enabled, possibly by default
Last modified: 2012-06-20 11:58:21 EDT
[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
## 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=).
(comments from Steve Grubb)
> But is it also as simple as 'service audit stop' and 'chkconfig audit
> Then the kernel will pass the audit messages to syslog?
> 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
Adding 'cc email@example.com 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.