lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 23 Mar 2007 12:50:09 -0600
From:	Joy Latten <latten@...tin.ibm.com>
To:	Eric Paris <eparis@...isplace.org>
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 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists