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

[Casey Schaufler]

--- "Timothy R. Chavez" <chavezt at gmail.com> wrote:
 
> Ok, if you're watching /home/casey/viruses and you
> mv/rename()
> viruses/ to fuzzybunnys/, you will lose the watch.

That is not what I would expect from an object
standpoint. I specified the object that I wanted
to watch and the rename did not change the object.
 
> The way it works
> is that the administrator specifies specific paths
> and if we leave
> such a path, we're no longer audited.

For this argument to make sense you would have to
keep an eye out /home/casey/viruses reappearing
in the namespace and marking it for audit.

    casey% mv viruses fuzzybunnys
    casey% mv fuzzybunnys viruses

should not disassociate the audit watch.

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

Make no mistake. The stated and genuine purpose
of an audit trail is to track the changes to the
security state of the system and the access control
decisions made by the system. This requires that
it be 100% unambiguous what it means to specify
a watched object. The issue here is that the
file system name space you are using to specify
what object to watch can be changed within the
system security policy by unprivileged users in
such a way as to disassociate the watch. Your
mechanism is unreliable.

If, on the other hand, you said

    # watch dev=8,9 inode=8776

that would be reliable, unambiguous, and
painful.

If you want to audit by pathname attaching
the audit watch to the inode is not right
because the two are not connected in any 
real way.


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