RE: audit 0.6 release
I can probably help here Casey, as Tom's been using Snare for a while.
(Tom - feel free to correct any mistaken assumptions though!) :)
On Thu, 2005-01-06 at 14:30 -0800, Casey Schaufler wrote:
--- "Browder, Tom" <Tom.Browder(a)fwb.srs.com> wrote:
> An example of a rule I want is to report when user X
> tries
> unsuccessfully to unlink a specific file.
Just to give you an idea of the magnitude of
what you're asking for:
1. Real UID == X, effective UID == X, logged on
as user X, or providing a remote service on
behalf of user X?
Usually, from a on-system filtering perspective, the auditor is
interested in real user ID only. The other ID's are very useful in
follow-up analysis though.
2. Unsuccessflly because he misspelled the path?
Unsuccessfully as in, "Tried to unlink /etc/passwd, but failed". User
motivations / finger slippages are a bit hard to cover ;)
3. Do you want to include rename with unlink?
What about unmounting the file system the
file is on?
Generally, an administrator will want to group a bunch of system calls
together under the banner of "attempted changes to a file" or "attempted
changes to file attributes" (or a combination thereof). This is likely
to include renames, unlinks, and so on.
4. Do you mean the path name "/tmp/foo", or the
inode 86753 on the root file system? What
about symlinks, mount points, and/or pseudo
filesystem redirections?
This is where it gets nasty doesn't it. ;)
Tom can correct me here, but I suspect that ideally:
* symlinks and links should be resolved. (even if the file linked to no
longer actually exists - the final path name should still be
reported/filtered on). Ideally, access to an symlink will actually
generate TWO events - one for the symlink (open - read), one for the
final file (open - as per user requirement).
* mount point/pfs resolution is a lower priority to security
administrators (as generally, on most systems, the mounting of a file
system is worth investigation in-of-itself), but still may be worth
doing.
* inodes are often transitory for the sorts of files many people are
interested in auditing (eg: Applix used to remove the old file, and
recreate the file, with a new inode, whenever you saved something! Erk.)
If the rules are kept in the kernel, how do you
intend to do that? You'll have to check either
every access to the file (assuming you know which
one it is) for unlinks or every unlink to see if
it's the file you're after.
If the audit daemon is going to look for this
event the kernel has to generate any event that
might fit the bill.
Bingo. The tradeoff of (potentially significant!) CPU/resource usage for
Auditing is a decision many organisations are prepared to accept -
monitoring every file-open, or unlink on the system is resource
intensive, but may be a critical requirement for many audit users. See
the vfs audit thread mentioned in my last email.
Snare works this way (bouncing every single file open through to the
audit daemon for resolution, when a user has requested file open
auditing). Not optimal, which is why filtering in-kernel may be more
appropriate - but even so, users have reported single-figure-percentage
reductions in performance when file auditing + regexp filtering is used.
I don't want to discourage anyone from putting
a compiler to their shoulder and lending a hand,
but the simple rule suggested is a lot trickier
than it looks.
Or perhaps not tricky exactly - just potentially prohibitively expensive
wit respect to resources, depending on the implementation.
Regards,
Leigh.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/