[RFC][PATCH] (#2) Prelim in-kernel file system auditing support

Casey Schaufler casey at schaufler-ca.com
Wed Jan 26 02:09:12 UTC 2005


--- "Timothy R. Chavez" <chavezt at gmail.com> wrote:


> Alright, I see better now the concern.  But because
> the audit
> information is associated with the inode via an
> administrator action,
> it still remains true that any access to that inode
> will be caught,
> from any namespace.  Correct?

Okay so far. Let's use an example other than
/etc/passwd. Let's say the admin wants to watch
/home/casey/viruses.

    # watch /home/casey/viruses/deadly37

Casey, expecting that they're on to him,

    casey% mv viruses fuzzybunnys

This is still good from an object standpoint
the object the admin tagged is still being
audited. I think your code will continue to
report this as "/home/casey/viruses/deadly37".

    casey% mkdir viruses
    casey% echo "Would be wrong." > viruses/deadly37

At this point you won't be seeing what you
probably expect in the audit trail, no trusted
administrator has to be tricked, and everything
was legal. You can't detect it directly either
as the inode you are watching isn't involved
in the process. If the audit record includes
the path that you tagged as well as the path that
you use to access the file you're going to be
okay as you'll be able to distinguish the current
viruses/deadly37 from the current
fuzzybunnys/deadly37 that was once called
viruses/deadly37.


=====
Casey Schaufler
casey at schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




More information about the Linux-audit mailing list