From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: linux-audit: reconstruct path names from syscall events?
Date: Wed, 10 Oct 2012 19:00:40 -0400 [thread overview]
Message-ID: <4547273.ji5OMfINXo@x2> (raw)
In-Reply-To: <CAOH1cHkowcv6k0D2bkXFcjU3k4UtG2WX3nSwNa267qmODNfs_w@mail.gmail.com>
On Wednesday, October 10, 2012 03:45:08 PM Mark Moseley wrote:
> On Tue, Oct 9, 2012 at 4:54 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > Again, relying on pathnames for forensics (or security in general) is
> > a serious mistake (cue unprintable comments about apparmor and similar
> > varieties of snake oil). And using audit as poor man's ktrace analog
> > is... misguided, to put it very mildly.
>
> Caveat: I'm just a sysadmin, so this stuff is as darn near "magic" as
> I get to see on a regular basis, so it's safe to expect some naivety
> and/or misguidedness on my part :)
>
> I'm just using it as a log of files that have been written/changed on
> moderately- to heavily-used systems. If there's another in-kernel
> mechanism that'd be better suited for that sort of thing (at least
> without adding a lot of overhead), I'd be definitely eager to know
> about it. It's a web hosting environment, with customer files all
> solely on NFS, so writes to the same directory can come from an
> arbitrary number of servers. When they get swamped with write
> requests, the amount of per-client stats exposed by our Netapp and
> Oracle NFS servers is often only enough to point us at a client server
> with an abusive user on it (but not much more, without turning on
> debugging). Having logs of who's doing writes would be quite useful,
> esp when writes aren't happening at that exact moment and wouldn't
> show up in tools like iotop. The audit subsystem seemed like the best
> fit for this kind of thing, but I'm more than open to whatever works.
The audit system is the best fit. But I think Al is saying there are some
limitations. i know that Eric pushed some patches a while back that makes a
stronger effort at collecting some of this information. What kernel are you
using?
-Steve
next prev parent reply other threads:[~2012-10-10 23:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 0:12 linux-audit: reconstruct path names from syscall events? John Feuerstein
2011-10-01 12:31 ` Steve Grubb
2011-10-03 19:42 ` Casey Schaufler
2011-10-04 17:02 ` Steve Grubb
2011-10-04 22:09 ` John Feuerstein
2011-10-07 13:50 ` Eric Paris
2011-10-07 14:04 ` Steve Grubb
2011-10-07 17:20 ` Casey Schaufler
2011-10-07 18:02 ` Steve Grubb
2011-10-07 18:27 ` Eric Paris
2011-10-07 21:38 ` Casey Schaufler
2011-10-10 12:54 ` Steve Grubb
2012-10-09 23:09 ` Mark Moseley
2012-10-09 23:29 ` Al Viro
2012-10-09 23:39 ` Al Viro
2012-10-09 23:47 ` Mark Moseley
2012-10-09 23:54 ` Al Viro
2012-10-10 22:45 ` Mark Moseley
2012-10-10 22:45 ` Mark Moseley
2012-10-10 23:00 ` Steve Grubb [this message]
2012-10-10 23:07 ` Mark Moseley
2012-10-11 17:27 ` Mark Moseley
2012-10-30 1:12 ` Mark Moseley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4547273.ji5OMfINXo@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.