Yes, it looks like you are right.
The easiest thing to do is authorize the socket's use of the
flow_cache_entry's xfrm_policy object if it has a security context.
Not really clean for following reasons:
(1) The flow_cache_entry object is a void* -- although flow_cache_lookup
only seems to be used to retrieve xfrm_policy objects now, the function is
written more generally.
(2) Multiple flow_cache_entry's may have same values (particularly on
outbound). The difference between the flows is due to the need for a
different security contexts, but the specific context is not known until
authorization time. If we cache the sid on the flowi, then we can have a
cache entry per security association and authorize the socket to this
flowi's sid.
Can we add the sid to the flowi?
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
