On Mon, 2007-07-02 at 20:44 +0100, Matthew Booth wrote:
I've hit a hurdle trying to do some post processing on audit
output
because PATH records contain paths relative to the CWD, rather than the
absolute path. How much effort would likely be involved in making sure
these paths were always absolute?
There has been a lot of work in this area to improve the reporting of
path information.
First I want to call your attention to the fact audit information is
emitted as independent records comprising a single audit event. The best
way to think of a record is that it is a single audit message and/or a
single line in a log file. If you are only looking at individual records
instead of all the records constituting an event you may be missing
information. For instance the path information is emitted in a separate
record. The audit parsing library (auparse) can reassemble independent
records into a single event (but currently only if the records occur
sequentially, non-sequential record assembly is a future feature).
The ability of the kernel to emit audit records with path information
has been evolving in different kernel versions. I'm sorry but I don't
have detailed version information on some of this. The AUDIT_AVC_PATH
record was added to give complete path information in conjunction with
an AUDIT_AVC record (i.e. these two records are members of a single
audit event). However in RHEL 5.1, kernel 2.6.22 the AUDIT_AVC_PATH
record is going away and the path instead will be in the avc record.
I'm not 100% positive, but I believe the work done to support
AUDIT_AVC_PATH by capturing path information prior to sys call
transition where only the inode is passed to the kernel will now result
in complete path information in other audit records as well, perhaps
Steve Grubb can give precise information on this.
Bottom line: It is recognized better path information is needed,
different audit/kernel versions have different support so it's a version
sensitive issue, and you must parse audit information as complete events
and not individual records.
--
John Dennis <jdennis(a)redhat.com>