[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1174669155.10788.60.camel@localhost.localdomain>
Date: Fri, 23 Mar 2007 12:59:15 -0400
From: Eric Paris <eparis@...isplace.org>
To: Joy Latten <latten@...tin.ibm.com>
Cc: James Morris <jmorris@...ei.org>,
David Miller <davem@...emloft.net>, selinux@...ho.nsa.gov,
netdev@...r.kernel.org, vyekkirala@...stedCS.com
Subject: Re: [PATCH]: Add security check before flushing SAD/SPD
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?
-Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists