linux-audit: reconstruct path names from syscall events?

[Casey Schaufler]

On 10/7/2011 11:27 AM, Eric Paris wrote:
> On Fri, 2011-10-07 at 10:20 -0700, Casey Schaufler wrote:
>> On 10/7/2011 6:50 AM, Eric Paris wrote:
>>> Casey only talked about the easy part of the reason the pathnames are
>>> useless.  He forgot to mention
>> I didn't forgot to mention the whole mount point thingy.
>> People always get hung up in coming up with ways to explain
>> around the problem, and having already identified the root
>> cause of the problem
> Ok fair enough.  I guess I just saw two root problems not just one.  You
> mentioned there existing multiple names for the same object.  I was
> thinking of the of there not existing any name for an object which makes
> sense at a 'system wide' level.  In any case.  We might be able to get
> some more pathname like info, but it's never (like Casey so sagely said)
> going to be truely useful....

The worst case is 4000 processes that opened the file under 4000
different pathnames, all of which have since been unlinked, doing
fchmod. At the time of fchmod there is no pathname that refers to
the file, although 4000 pathnames are associated with the object
whose mode is getting changed. The dev/inode pair is the only
externally visible identifier that could possibly be used to
name the file in the log, and as you point out, the dev is not
reliable.

Now even with that, a path name could be useful. It just can't
be considered definitive or unique. As for audit tracking, you
really ought to be able to say things like "show me everything
that happens to the file that is currently called /etc/shadow"
and "show me everything that happens to any file called /etc/shadow",
even though the two statements are radically different underneath.
The problem is that 99 44/100% of the people looking at or setting
up audit trails are going to be disinterested in or possibly
incapable of making the distinction. Let's face it, most people
shouldn't be using computers capable of running anything except
AngryBirds.



>
> -Eric
>
>