Re: [RFC][PATCH] (#2) Prelim in-kernel file system auditing support
--- "Timothy R. Chavez" <chavezt(a)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(a)schaufler-ca.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com