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] [thread-next>] [day] [month] [year] [list]
Message-ID: <51125744.3030905@gmail.com>
Date:	Wed, 06 Feb 2013 08:14:44 -0500
From:	jamal <j.hadi123@...il.com>
To:	Steffen Klassert <steffen.klassert@...unet.com>
CC:	Romain KUNTZ <r.kuntz@...lavors.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	herbert@...dor.apana.org.au,
	Emmanuel THIERRY <emmanuel.thierry@...ecom-bretagne.eu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jamal Hadi Salim <hadi@...erus.ca>
Subject: Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.

Hi Steffen,

On 13-02-05 03:12 AM, Steffen Klassert wrote:
>> For example, executing the below commands in that order succeed:
>>   ip -6 xfrm policy flush
>>   ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out mark 1 mask 0xffffffff
>>   ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out
> The policy with mark 1 is the first we find. The policy passes the
> mark check and if the flow matches the selectors, we use this policy.
>
>> But it fails in the reverse order:
>>   ip -6 xfrm policy flush
>>   ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out
>>   ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out mark 1 mask 0xffffffff
>>   RTNETLINK answers: File exists
> With this scenario, we would find the policy with mark and mask 0 first.
> This policy passes the mark check too. So we would use this policy if the
> flow matches the selectors, but the flow asked for a policy with mark 1.

I think the intent Romain is expressing is reasonable and should resolved at
insertion time(xfrm_policy_insert()).
i.e even though the policy (such as mark=1) is inserted afterwards, at
insertion time if it proves it is more specific and not duplicate, it 
should be
inserted ahead of the mark=0.
The runtime check will work then.

cheers,
jamal





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

Powered by Openwall GNU/*/Linux Powered by OpenVZ