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

[Serge Hallyn]

On Wed, 2005-01-26 at 08:44 -0800, Casey Schaufler wrote: 
> --- "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.

In the case of shadow all you care about is the new object.  You have a
log entry saying that the object was moved, now you wait for a new one
to be created.  You care about who is writing to the pathname which will
be used for authentication.

The case you're mentioning is when we're more concerned about protecting
the data itself.  We've talked about supporting this, but it would have
to be very clear to the user which type of audit watch is being
requested.  One of the main reasons we've not addressed the issue yet is
because in order for this type of tracking to survive a reboot, we would
have to either make use of extended attributes, or have the kernel
append to the list of audit rules stored in the config file.  The latter
is clearly unacceptable, and the former would be nice to avoid if
possible.

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

Yes, and so when we know that login will check whatever object happens
to be located at /etc/shadow, then the object which can be reached
through /etc/shadow, whatever dentry it was actually reached through,
must be audited.

Note that the case you mention of
	mv filename tempfile
	mv tempfile filename
would result in filename being audited again after the second mv under
the current behavior.  But any access to tempfile between the two moves
would not be audited.

(At least this is the intent.  I'm not yet convinced that renames and
unlinks are all currently correctly handled, only because I haven't had
time to look for that yet)

>  This requires that
> it be 100% unambiguous what it means to specify
> a watched object.

Absolutely.

>     # watch dev=8,9 inode=8776
> 
> that would be reliable, unambiguous, and
> painful.

Reliable depends on what you're trying to accomplish.  It would be
worthless for the shadow case, because after the next run of passwd,
inode 8776 is no longer useful.

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

Attaching to the inode is necessary because it is the only way to catch
every access to the object attached to this dentry, regardless of which
dentry (in whatever namespace) was used to access the inode.

-- 
Serge Hallyn <serue at us.ibm.com>