Re: Decoding arguments passed to system calls

On Tue, 2007-07-03 at 10:48 +1200, Darryl Dixon - Winterhouse Consulting wrote: > Hi Matt, > > Thank you for your very thorough response. What you say about not being > able to audit 'write()' is worrying to me. The problem with auditing write > by inference from open(), is that one doesn't know *when* the file was > written, or even if it really ever was at all (eg, was data written > continuously from open() to close(), or only sporadically over the course > of hours or days?). Auditing for actual alterations is definitely > something that we need to be able to track. Assuming for a moment that we > have beefy enough hardware ( heh ), can the path be extracted from write() > as with your example for open() above? My assumption would have been that > CWD reflected only where the exe was launched from, and not necessarily > where the write()-en file was located... Well, you can audit write(). The question is whether you can handle the resulting data volume. read() and write() don't generate a PATH record. The only time at which a path is relevant is at the time the file is opened. Once the file is opened, it can have zero or more paths, which can all change without affecting the open file. An open file is genuinely divorced from its path. That said, it's *not* divorced from its filesystem, which I understand is what you're really looking for. Unfortunately that information doesn't appear to live on its own in the audit trail, and it's not available to filter on for these calls. This would leave you having to audit all read() and write() calls and filtering them in post-processing. I doubt this would be a practical solution.