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.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
Attachments:
- signature.asc (application/pgp-signature — 189 bytes)