netdev - Re: [PATCH][IPSEC][6/7] inter address family ipsec tunnel

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: <20061204033041.GA11572@gondor.apana.org.au>
Date:	Mon, 4 Dec 2006 14:30:41 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	kazunori@...azawa.org, miika@....fi, Diego.Beltrami@...t.fi,
	netdev@...r.kernel.org, usagi-core@...ux-ipv6.org
Subject: Re: [PATCH][IPSEC][6/7] inter address family ipsec tunnel

On Sun, Dec 03, 2006 at 07:12:08PM -0800, David Miller wrote:
> 
> For the time being I'm thinking of using the following
> patch.  I removed the xp->family clobbering, the AF_KEY
> changes don't do this, so there is no reason for the
> xfrm_user side to do it either.

This patch looks fine to me.

I am to blame for the genesis of this problem so here is a bit
of background :)

At the very start we had one family field and that was
xfrm_userpolicy_info->sel->family.  Since the only transforms
were of the same family it was sufficient.

I then added xfrm_user_tmpl->family in order to allow for the
possibility of inter-family transforms.  Unfortunately I didn't
add a check to the kernel to verify its value.  As a result,
Openswan was able to get away with leaving it as zero.

If anyone is overly worried about the potential of apps leaving
garbage rather than zero in this field, we can combine it with
xfrm_userpolicy_info->flags which should currently be zero.

So all we need to do is add a new flag (perhaps XFRM_POLICY_INTERFAMILY)
which must be set for the template family fields to be used.

As for xfrm_policy->family, it's an internal field that has lived
past its use-by date.  It should be replaced either by xp->sel.family
or xp->xfrm_vec[x].family where appropriate.

The family only makes sense when interpreted together with a layer
of address.  So we don't really need an overall family for a policy.

I hope that at the end of this patch series xp->family can be removed
altogether.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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