On Fri, 2007-03-23 at 12:59 -0400, Eric Paris wrote: > On Fri, 2007-03-23 at 10:33 -0600, Joy Latten wrote: > > On Fri, 2007-03-23 at 01:39 -0400, Eric Paris wrote: > > > > > > > > In either case though proper auditing needs to be addressed. I see that > > > the first patch from Joy wouldn't audit deletion failures. It appears > > > to me if the check is done per policy then the security hook return code > > > needs to be recorded and passed to xfrm_audit_log instead of the hard > > > coded 1 result used now. > > > > > > Assuming we go with James's double loop what should we be auditing for a > > > security hook denial? Just audit the first policy entry which we tried > > > to remove but couldn't and then leave the rest of the auditing in those > > > functions the way it is now in case there was no denial, calling > > > xfrm_audit_log with a hard coded 1 for the result? > > > > > Actually, I thought the original intent of the ipsec auditing was to > > just audit changes made to the SAD/SPD databases, not securiy hook > > denials, right? > > Then what is the point of the 'result' field that we capture and log in > xfrm_audit_log if the only things you care to audit are successful > changes to the databases? > Yes, I think we do want to audit the security denial since it is the reason we could not change the policy. In the flush case it seem it will be the only reason. As you suggested, I will audit the first denial since this is the reason the flush will fail.
But sometimes, in other cases, the delete or add could fail for other reasons too such as not being able to allocate memory, not finding the entry, etc... which is passed in the result field. Regards, Joy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
