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

Timothy R. Chavez chavezt at gmail.com
Wed Jan 26 04:28:40 UTC 2005


On Tue, 25 Jan 2005 18:09:12 -0800 (PST), Casey Schaufler
<casey at schaufler-ca.com> wrote:
> 
> --- "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".

Ok, if you're watching /home/casey/viruses and you mv/rename()
viruses/ to fuzzybunnys/, you will lose the watch.  The way it works
is that the administrator specifies specific paths and if we leave
such a path, we're no longer audited.

Also, when we watch /home/case/viruses/, it's important to note that
we are not watching anything within viruses/ and that access to
files/directories within viruses/ do not necessarly "pass through"
viruses/.  So, if we do "cat /home/casey/viruses/deadly37" no audit
record for "viruses/" would be generated and recorded.

> 
>     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.

You're right, if that directory were renamed, and a new one created,
the new directory would be auditable, and the one you were interested
in would not.  But, really...  the user could also DoS the system in a
CAPP environment (can't use the rate limit).  I guess what this boils
down to is requirement.  As far as I know, for this type of
certification, monitoring a user isn't the goal of file system
auditing, but rather, we're trying to validate and verify the kernel's
response/reaction to stimulus/action within the filesystem.

> 
> =====
> 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
> 


-- 
- Timothy R. Chavez




More information about the Linux-audit mailing list