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

On Wed, 2005-01-26 at 08:44 -0800, Casey Schaufler wrote: 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. 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) Absolutely. 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. 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(a)us.ibm.com&gt;