On Mon, 02 Jul 2007 20:44:55 BST, Matthew Booth said: Probably quite a bit, especially if they traverse symlinks and the like. Additionally, you'd need to track *current* state of $CWD, as the absolute path will change each time a chdir() happens, or if somebody does something like 'mv . ../../foo'. Particularly evil to track: cd foo/bar/baz ./myprog & cd ../ mv baz .. Where's myprog's ../../bin pointing now? And how would your post processor know that happened?

On Mon, 2007-07-02 at 20:44 +0100, Matthew Booth wrote: 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&gt;

On Mon, 2007-07-02 at 22:02 +0100, Matthew Booth wrote: A few quick points: enVision can only reassemble records into event if you are transmitting the record header information, are you? If so and enVision can properly interpret the header and coalesce matching headers you're all set. There is a lot of planned work surrounding aggregate auditing from multiple hosts, perhaps not relevant to the current evaluation of enVision, but be aware this technology area is in high churn. For example the current audit system now allows for interested third parties to monitor audit information, no need for custom audit daemons, there is a well defined framework for monitoring. -- John Dennis <jdennis(a)redhat.com&gt;

On Monday 02 July 2007 03:44:55 pm Matthew Booth wrote: Actually, they are exactly what was passed to the kernel. If its an absolute path, then you will get that and the CWD record is not needed. But if the path starts with a '.', then you have to pay attention to the CWD record. Also, if you have a chroot situation, you must pay attention to the CWD record. The PATH record is from the PoV of the application using files. We only record what the kernel is working with. There is no chance to do anything during the recording side and save that for post-processing. -Steve