Modifying the flowi structure will not help, as we would need to compute
the sid of the request which is tantamount to authorization.
Since this code simply iterates through the existing entries,
authorization of a match is appropriate. The only anxiety I have is that
the object is untyped, and I do not see a way to verify that the object is
a xfrm_policy. Is there an appropriate way to identify these as
xfrm_policy objects? xfrm_lookup and __xfrm_policy_check expect that only
xfrm_policies are returned.
Shall I submit the patch with the authorization?
Regards,
Trent.
------------------------------------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225
Herbert Xu <[EMAIL PROTECTED]>
07/07/2005 06:00 AM
To: Trent Jaeger/Watson/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
netdev@vger.kernel.org, Serge E Hallyn/Austin/[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH 1/2] LSM-IPSec Networking Hooks
On Wed, Jul 06, 2005 at 04:24:53PM -0400, jaegert wrote:
>
> diff -puN net/core/flow.c~lsm-xfrm-nethooks net/core/flow.c
> --- linux-2.6.12-git3-xfrm/net/core/flow.c~lsm-xfrm-nethooks 2005-06-21
15:56:40.000000000 -0400
> +++ linux-2.6.12-git3-xfrm-root/net/core/flow.c 2005-06-21
15:56:40.000000000 -0400
> @@ -162,7 +162,7 @@ static int flow_key_compare(struct flowi
> return 0;
> }
>
> -void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
> +void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family,
u8 dir,
> flow_resolve_t resolver)
> {
> struct flow_cache_entry *fle, **head;
> @@ -221,7 +221,7 @@ nocache:
> void *obj;
> atomic_t *obj_ref;
>
> - resolver(key, family, dir, &obj,
&obj_ref);
> + resolver(key, sk, family, dir, &obj,
&obj_ref);
>
> if (fle) {
> fle->genid =
atomic_read(&flow_cache_genid);
This bit looks problematic. For raw sockets you can have the same
flow corresponding to multiple sockets. However, let's put that aside
for now since at least you'll need to be root to get them.
However, even with TCP/UDP sockets, this could happen:
Socket 1 with security context A does flow_cache_lookup thus populating
the cache with the appropriate entry.
Socket 1 is closed.
Socket 2 is opened with the same src/dst addr/port but with a different
security context B. When it does flow_cache_lookup it could pick up the
cached entry from the first socket, right?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
