linux-audit: reconstruct path names from syscall events?

[Mark Moseley]

On Wed, Oct 10, 2012 at 4:07 PM, Mark Moseley <moseleymark at gmail.com> wrote:
> On Wed, Oct 10, 2012 at 4:00 PM, Steve Grubb <sgrubb at redhat.com> wrote:
>> On Wednesday, October 10, 2012 03:45:08 PM Mark Moseley wrote:
>>> On Tue, Oct 9, 2012 at 4:54 PM, Al Viro <viro at 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?
>
> Yup, understood. I've been playing with a variety of boxes, but mostly
> within the 3.0.x and 3.2.x series. I'll drop 3.5.6 on some of these
> boxes and see if my issues are already fixed (and proceed directly to
> foot-in-mouth chagrined stage -- usually takes slightly longer to get
> to that stage).

Just gave 3.5.6 a shot and in these two particular cases, the result
is the same: chroot'd actions are logged in the audit entry relative
to the chroot, and the unlinkat/chmodat/chownat audit log entries only
have one item with the bare filename and no indication of directory.