netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-09-30 14:44                   ` James Morris
@ 2006-10-01  6:27                     ` James Morris
  2006-10-02 11:20                       ` Evgeniy Polyakov
  0 siblings, 1 reply; 10+ messages in thread
From: James Morris @ 2006-10-01  6:27 UTC (permalink / raw)
  To: David S. Miller, Herbert Xu
  Cc: netdev, Stephen Smalley, Evgeniy Polyakov, Venkat Yekkirala,
	Paul Moore

Please review this patch carefully.  It addresses a couple of issues.

When a security module is loaded (in this case, SELinux), the 
security_xfrm_policy_lookup() hook can return an access denied permission 
(or other error).  We were not handling that correctly, and in fact 
inverting the return logic and propagating a false "ok" back up to 
xfrm_lookup(), which then allowed packets to pass as if they were not 
associated with an xfrm policy.

The way I was seeing the problem was when connecting via IPsec to a 
confined service on an SELinux box (vsftpd), which did not have the 
appropriate SELinux policy permissions to send packets via IPsec.

The first SYNACK would be blocked, because of an uncached lookup via 
flow_cache_lookup(), which would fail to resolve an xfrm policy because 
the SELinux policy is checked at that point via the resolver.

However, retransmitted SYNACKs would then find a cached flow entry when 
calling into flow_cache_lookup() with a null xfrm policy, which is 
interpreted by xfrm_lookup() as the packet not having any associated 
policy and similarly to the first case, allowing it to pass without 
transformation.

The solution presented here is to first ensure that errno values are 
correctly propagated all the way back up through the various call chains 
from security_xfrm_policy_lookup(), and handled correctly.

Then, flow_cache_lookup() is modified, so that if the policy resolver 
fails (typically a permission denied via the security module), the flow 
cache entry is killed rather than having a null policy assigned (which 
indicates that the packet can pass freely).  This also forces any future 
lookups for the same flow to consult the security module (e.g. SELinux) 
for current security policy (rather than, say, caching the error on the 
flow cache entry).

I've done quite a bit of testing and not seen any problems, although the 
patch could certainly do with further review.

Evgeniy, please let me know if this fixes your problem.


Signed-off-by: James Morris <jmorris@namei.org>


---

 include/net/flow.h     |    2 -
 net/core/flow.c        |   42 +++++++++++++++++++----------
 net/xfrm/xfrm_policy.c |   70 ++++++++++++++++++++++++++++++++++++++-----------
 3 files changed, 84 insertions(+), 30 deletions(-)


diff -purN -X dontdiff net-2.6.o/include/net/flow.h net-2.6.w/include/net/flow.h
--- net-2.6.o/include/net/flow.h	2006-09-29 11:33:58.000000000 -0400
+++ net-2.6.w/include/net/flow.h	2006-09-30 23:50:32.000000000 -0400
@@ -97,7 +97,7 @@ struct flowi {
 #define FLOW_DIR_FWD	2
 
 struct sock;
-typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
+typedef int (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp);
 
 extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
diff -purN -X dontdiff net-2.6.o/net/core/flow.c net-2.6.w/net/core/flow.c
--- net-2.6.o/net/core/flow.c	2006-09-29 11:33:59.000000000 -0400
+++ net-2.6.w/net/core/flow.c	2006-10-01 01:07:24.000000000 -0400
@@ -85,6 +85,14 @@ static void flow_cache_new_hashrnd(unsig
 	add_timer(&flow_hash_rnd_timer);
 }
 
+static void flow_entry_kill(int cpu, struct flow_cache_entry *fle)
+{
+	if (fle->object)
+		atomic_dec(fle->object_ref);
+	kmem_cache_free(flow_cachep, fle);
+	flow_count(cpu)--;
+}
+
 static void __flow_cache_shrink(int cpu, int shrink_to)
 {
 	struct flow_cache_entry *fle, **flp;
@@ -100,10 +108,7 @@ static void __flow_cache_shrink(int cpu,
 		}
 		while ((fle = *flp) != NULL) {
 			*flp = fle->next;
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-			kmem_cache_free(flow_cachep, fle);
-			flow_count(cpu)--;
+			flow_entry_kill(cpu, fle);
 		}
 	}
 }
@@ -220,24 +225,33 @@ void *flow_cache_lookup(struct flowi *ke
 
 nocache:
 	{
+		int err;
 		void *obj;
 		atomic_t *obj_ref;
 
-		resolver(key, family, dir, &obj, &obj_ref);
+		err = resolver(key, family, dir, &obj, &obj_ref);
 
 		if (fle) {
-			fle->genid = atomic_read(&flow_cache_genid);
-
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-
-			fle->object = obj;
-			fle->object_ref = obj_ref;
-			if (obj)
-				atomic_inc(fle->object_ref);
+			if (err) {
+				/* Force security policy check on next lookup */
+				*head = fle->next;
+				flow_entry_kill(cpu, fle);
+			} else {
+				fle->genid = atomic_read(&flow_cache_genid);
+				
+				if (fle->object)
+					atomic_dec(fle->object_ref);
+					
+				fle->object = obj;
+				fle->object_ref = obj_ref;
+				if (obj)
+					atomic_inc(fle->object_ref);
+			}
 		}
 		local_bh_enable();
 
+		if (err)
+			obj = ERR_PTR(err);
 		return obj;
 	}
 }
diff -purN -X dontdiff net-2.6.o/net/xfrm/xfrm_policy.c net-2.6.w/net/xfrm/xfrm_policy.c
--- net-2.6.o/net/xfrm/xfrm_policy.c	2006-09-29 11:34:00.000000000 -0400
+++ net-2.6.w/net/xfrm/xfrm_policy.c	2006-10-01 01:53:21.000000000 -0400
@@ -880,30 +880,32 @@ out:
 }
 EXPORT_SYMBOL(xfrm_policy_walk);
 
-/* Find policy to apply to this flow. */
-
+/*
+ * Find policy to apply to this flow.
+ *
+ * Returns 0 if policy found, else an -errno.
+ */
 static int xfrm_policy_match(struct xfrm_policy *pol, struct flowi *fl,
 			     u8 type, u16 family, int dir)
 {
 	struct xfrm_selector *sel = &pol->selector;
-	int match;
+	int match, ret = -ESRCH;
 
 	if (pol->family != family ||
 	    pol->type != type)
-		return 0;
+		return ret;
 
 	match = xfrm_selector_match(sel, fl, family);
-	if (match) {
-		if (!security_xfrm_policy_lookup(pol, fl->secid, dir))
-			return 1;
-	}
+	if (match)
+		ret = security_xfrm_policy_lookup(pol, fl->secid, dir);
 
-	return 0;
+	return ret;
 }
 
 static struct xfrm_policy *xfrm_policy_lookup_bytype(u8 type, struct flowi *fl,
 						     u16 family, u8 dir)
 {
+	int err;
 	struct xfrm_policy *pol, *ret;
 	xfrm_address_t *daddr, *saddr;
 	struct hlist_node *entry;
@@ -919,7 +921,15 @@ static struct xfrm_policy *xfrm_policy_l
 	chain = policy_hash_direct(daddr, saddr, family, dir);
 	ret = NULL;
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir)) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else {
 			ret = pol;
 			priority = ret->priority;
 			break;
@@ -927,36 +937,53 @@ static struct xfrm_policy *xfrm_policy_l
 	}
 	chain = &xfrm_policy_inexact[dir];
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir) &&
-		    pol->priority < priority) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else if (pol->priority < priority) {
 			ret = pol;
 			break;
 		}
 	}
 	if (ret)
 		xfrm_pol_hold(ret);
+fail:
 	read_unlock_bh(&xfrm_policy_lock);
 
 	return ret;
 }
 
-static void xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
+static int xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp)
 {
 	struct xfrm_policy *pol;
+	int err = 0;
 
 #ifdef CONFIG_XFRM_SUB_POLICY
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_SUB, fl, family, dir);
-	if (pol)
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
+	if (pol || err)
 		goto end;
 #endif
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_MAIN, fl, family, dir);
-
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
 #ifdef CONFIG_XFRM_SUB_POLICY
 end:
 #endif
 	if ((*objp = (void *) pol) != NULL)
 		*obj_refp = &pol->refcnt;
+	return err;
 }
 
 static inline int policy_to_flow_dir(int dir)
@@ -1294,6 +1321,10 @@ restart:
 
 		policy = flow_cache_lookup(fl, dst_orig->ops->family,
 					   dir, xfrm_policy_lookup);
+		if (IS_ERR(policy)) {
+			err = PTR_ERR(policy);
+			goto error;
+		}
 	}
 
 	if (!policy)
@@ -1340,6 +1371,10 @@ restart:
 							    fl, family,
 							    XFRM_POLICY_OUT);
 			if (pols[1]) {
+				if (IS_ERR(pols[1])) {
+					err = PTR_ERR(pols[1]);
+					goto error;
+				}
 				if (pols[1]->action == XFRM_POLICY_BLOCK) {
 					err = -EPERM;
 					goto error;
@@ -1578,6 +1613,9 @@ int __xfrm_policy_check(struct sock *sk,
 		pol = flow_cache_lookup(&fl, family, fl_dir,
 					xfrm_policy_lookup);
 
+	if (IS_ERR(pol))
+		return 0;
+
 	if (!pol) {
 		if (skb->sp && secpath_has_nontransport(skb->sp, 0, &xerr_idx)) {
 			xfrm_secpath_reject(xerr_idx, skb, &fl);
@@ -1596,6 +1634,8 @@ int __xfrm_policy_check(struct sock *sk,
 						    &fl, family,
 						    XFRM_POLICY_IN);
 		if (pols[1]) {
+			if (IS_ERR(pols[1]))
+				return 0;
 			pols[1]->curlft.use_time = (unsigned long)xtime.tv_sec;
 			npols ++;
 		}

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH] Fix for IPsec leakage with SELinux enabled
@ 2006-10-01 20:55 Venkat Yekkirala
  2006-10-02  1:44 ` James Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Venkat Yekkirala @ 2006-10-01 20:55 UTC (permalink / raw)
  To: James Morris, David S. Miller, Herbert Xu
  Cc: netdev, Stephen Smalley, Evgeniy Polyakov, Venkat Yekkirala,
	Paul Moore, Chad Hanson

> The way I was seeing the problem was when connecting via IPsec to a 
> confined service on an SELinux box (vsftpd), which did not have the 
> appropriate SELinux policy permissions to send packets via IPsec.
> 
> The first SYNACK would be blocked,

Given that the resolver fails to find a policy here, I am trying to
understand what exactly is blocking it (the first SYNACK) from
proceeding without IPSec.

> because of an uncached lookup via 
> flow_cache_lookup(), which would fail to resolve an xfrm 
> policy because 
> the SELinux policy is checked at that point via the resolver.
> 
> However, retransmitted SYNACKs would then find a cached flow 
> entry when 
> calling into flow_cache_lookup() with a null xfrm policy, which is 
> interpreted by xfrm_lookup() as the packet not having any associated 
> policy and similarly to the first case, allowing it to pass without 
> transformation.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-01 20:55 Venkat Yekkirala
@ 2006-10-02  1:44 ` James Morris
  0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2006-10-02  1:44 UTC (permalink / raw)
  To: Venkat Yekkirala
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Evgeniy Polyakov, Paul Moore, Chad Hanson

On Sun, 1 Oct 2006, Venkat Yekkirala wrote:

> > The way I was seeing the problem was when connecting via IPsec to a 
> > confined service on an SELinux box (vsftpd), which did not have the 
> > appropriate SELinux policy permissions to send packets via IPsec.
> > 
> > The first SYNACK would be blocked,
> 
> Given that the resolver fails to find a policy here, I am trying to
> understand what exactly is blocking it (the first SYNACK) from
> proceeding without IPSec.

You're right.  My explanation there was for the case where I'd modified 
the code to propagate the SELinux denial back to xfrm_lookup(), and not 
for the original issue (sorry, it's been a long week).

In the original case, all packets originating from a confined domain will 
bypass ipsec.  During xfrm_lookup, flow_cache_lookup() returns NULL 
policy:

xfrm_lookup()
{
	...

	if (!policy) {
                /* To accelerate a bit...  */
                if ((dst_orig->flags & DST_NOXFRM) ||
                    !xfrm_policy_count[XFRM_POLICY_OUT])
                        return 0;

                policy = flow_cache_lookup(fl, dst_orig->ops->family,
                                           dir, xfrm_policy_lookup);
        }

        if (!policy)
                return 0;  <- bad
	...
}

The call chain is:

flow_cache_lookup()
  xfrm_policy_lookup()
   xfrm_policy_lookup_bytype()
     xfrm_policy_match() {
       xfrm_selector_match => returns true, then
         security_xfrm_policy_lookup => returns -EACCESS
     }

then
     
xfrm_policy_match() => returns 0
xfrm_policy_lookup_bytype => returns 0
xfrm_policy_lookup() => sets obj to NULL w/ void return
flow_cache_lookup() => returns NULL
xfrm_lookup => returns 0

and the packet proceeds without error and with no transform applied (i.e. 
leaked as cleartext).

The first component of the fix is to propagate errors back up to callers 
via the flow cache resolver, and handle them correctly, as this is where 
we can experience security module denials.

The second component is to then ensure that, on failure, we kill the new 
flow cache entry created during lookup, so that it is not subsequently 
looked up with a null policy (i.e. allowing future packets to leak) and to 
force the security hook to be called again in case the policy has changed.  

Hope that clarifies.
    

- James
-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-01  6:27                     ` [PATCH] Fix for IPsec leakage with SELinux enabled James Morris
@ 2006-10-02 11:20                       ` Evgeniy Polyakov
  2006-10-02 13:31                         ` James Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Evgeniy Polyakov @ 2006-10-02 11:20 UTC (permalink / raw)
  To: James Morris
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Venkat Yekkirala, Paul Moore

On Sun, Oct 01, 2006 at 02:27:13AM -0400, James Morris (jmorris@namei.org) wrote:
> Please review this patch carefully.  It addresses a couple of issues.
> 
> When a security module is loaded (in this case, SELinux), the 
> security_xfrm_policy_lookup() hook can return an access denied permission 
> (or other error).  We were not handling that correctly, and in fact 
> inverting the return logic and propagating a false "ok" back up to 
> xfrm_lookup(), which then allowed packets to pass as if they were not 
> associated with an xfrm policy.
> 
> The way I was seeing the problem was when connecting via IPsec to a 
> confined service on an SELinux box (vsftpd), which did not have the 
> appropriate SELinux policy permissions to send packets via IPsec.
> 
> The first SYNACK would be blocked, because of an uncached lookup via 
> flow_cache_lookup(), which would fail to resolve an xfrm policy because 
> the SELinux policy is checked at that point via the resolver.
> 
> However, retransmitted SYNACKs would then find a cached flow entry when 
> calling into flow_cache_lookup() with a null xfrm policy, which is 
> interpreted by xfrm_lookup() as the packet not having any associated 
> policy and similarly to the first case, allowing it to pass without 
> transformation.
> 
> The solution presented here is to first ensure that errno values are 
> correctly propagated all the way back up through the various call chains 
> from security_xfrm_policy_lookup(), and handled correctly.
> 
> Then, flow_cache_lookup() is modified, so that if the policy resolver 
> fails (typically a permission denied via the security module), the flow 
> cache entry is killed rather than having a null policy assigned (which 
> indicates that the packet can pass freely).  This also forces any future 
> lookups for the same flow to consult the security module (e.g. SELinux) 
> for current security policy (rather than, say, caching the error on the 
> flow cache entry).
> 
> I've done quite a bit of testing and not seen any problems, although the 
> patch could certainly do with further review.
> 
> Evgeniy, please let me know if this fixes your problem.

With that patch applied I got kernel panic after some time.
Unfortunately I have not installed serial console, so the most
interesting bits of the stack dump are not visible.
Here is the last ones which are on the screen:
ip_rcv
ip_rcv_finish
packet_rcv_spkt
ip_rcv
netif_receive_skb
sys_accept
skge_poll

and some other uninteresting stuff like hrtimer, softirq and the like...

EIP is at xfrm_lookup+0x43d/0x470

Notice packet socket handler in the trace, may be it can help - I ran
system with tcpdump started.

-- 
	Evgeniy Polyakov

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-02 11:20                       ` Evgeniy Polyakov
@ 2006-10-02 13:31                         ` James Morris
  2006-10-02 13:42                           ` Evgeniy Polyakov
  0 siblings, 1 reply; 10+ messages in thread
From: James Morris @ 2006-10-02 13:31 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Venkat Yekkirala, Paul Moore

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> > Evgeniy, please let me know if this fixes your problem.
> 
> With that patch applied I got kernel panic after some time.
> Unfortunately I have not installed serial console, so the most
> interesting bits of the stack dump are not visible.
> Here is the last ones which are on the screen:
> ip_rcv
> ip_rcv_finish
> packet_rcv_spkt
> ip_rcv
> netif_receive_skb
> sys_accept
> skge_poll
> 
> and some other uninteresting stuff like hrtimer, softirq and the like...
> 
> EIP is at xfrm_lookup+0x43d/0x470
> 
> Notice packet socket handler in the trace, may be it can help - I ran
> system with tcpdump started.

What kind of traffic was running over the system?  What is the IPsec and 
SELinux configuration?

Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's 
at the EIP offset?

(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 
0xc02cc7e2 <xfrm_lookup>
(gdb) l *(0xc02cc7e2 + 0x043d)


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-02 13:31                         ` James Morris
@ 2006-10-02 13:42                           ` Evgeniy Polyakov
  2006-10-02 14:05                             ` James Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Evgeniy Polyakov @ 2006-10-02 13:42 UTC (permalink / raw)
  To: James Morris
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Venkat Yekkirala, Paul Moore

On Mon, Oct 02, 2006 at 09:31:36AM -0400, James Morris (jmorris@namei.org) wrote:
> What kind of traffic was running over the system?  What is the IPsec and 
> SELinux configuration?

I had login through ssh, started racoon and setup keys.
SElinu is configured by default in FC5 system with enforcing mode.

I switched off to different window and after some time, not immediately,
remote system stopped to answer.

There were no heavy traffic definitely.
It looks like some timeout expired and someone tried to do xfrm_lookup.

> Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's 
> at the EIP offset?
> 
> (gdb) p xfrm_lookup
> $1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 
> 0xc02cc7e2 <xfrm_lookup>
> (gdb) l *(0xc02cc7e2 + 0x043d)

(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 0xc0301326 <xfrm_lookup>
(gdb) l *(0xc0301326+0x043d)
0xc0301763 is in xfrm_lookup (include/asm/atomic.h:126).
121      */ 
122     static __inline__ int atomic_dec_and_test(atomic_t *v)
123     {
124             unsigned char c;
125
126             __asm__ __volatile__(
127                     LOCK_PREFIX "decl %0; sete %1"
128                     :"+m" (v->counter), "=qm" (c)
129                     : : "memory");
130             return c != 0;

Probably reference counter is inside freed object...

> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-02 13:42                           ` Evgeniy Polyakov
@ 2006-10-02 14:05                             ` James Morris
  0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2006-10-02 14:05 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Venkat Yekkirala, Paul Moore

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> Probably reference counter is inside freed object...

I think I know what it is (xfrm_lookup needs to just return on flow cache 
lookup failure, not goto error and free the dst).  Patch forthcoming.




- James
-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH] Fix for IPsec leakage with SELinux enabled
@ 2006-10-02 17:09 Venkat Yekkirala
  2006-10-02 18:39 ` James Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Venkat Yekkirala @ 2006-10-02 17:09 UTC (permalink / raw)
  To: James Morris, Venkat Yekkirala
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Evgeniy Polyakov, Paul Moore, Chad Hanson

> On Sun, 1 Oct 2006, Venkat Yekkirala wrote:
> 
> > > The way I was seeing the problem was when connecting via 
> IPsec to a 
> > > confined service on an SELinux box (vsftpd), which did 
> not have the 
> > > appropriate SELinux policy permissions to send packets via IPsec.
> > > 
> > > The first SYNACK would be blocked,
> > 
> > Given that the resolver fails to find a policy here, I am trying to
> > understand what exactly is blocking it (the first SYNACK) from
> > proceeding without IPSec.
> 
> You're right.  My explanation there was for the case where 
> I'd modified 
> the code to propagate the SELinux denial back to 
> xfrm_lookup(), and not 
> for the original issue (sorry, it's been a long week).
> 
> In the original case, all packets originating from a confined 
> domain will 
> bypass ipsec.  During xfrm_lookup, flow_cache_lookup() returns NULL 
> policy:
> 
> xfrm_lookup()
> {
> 	...
> 
> 	if (!policy) {
>                 /* To accelerate a bit...  */
>                 if ((dst_orig->flags & DST_NOXFRM) ||
>                     !xfrm_policy_count[XFRM_POLICY_OUT])
>                         return 0;
> 
>                 policy = flow_cache_lookup(fl, dst_orig->ops->family,
>                                            dir, xfrm_policy_lookup);
>         }
> 
>         if (!policy)
>                 return 0;  <- bad
> 	...
> }
> 
> The call chain is:
> 
> flow_cache_lookup()
>   xfrm_policy_lookup()
>    xfrm_policy_lookup_bytype()
>      xfrm_policy_match() {
>        xfrm_selector_match => returns true, then
>          security_xfrm_policy_lookup => returns -EACCESS
>      }
> 
> then
>      
> xfrm_policy_match() => returns 0
> xfrm_policy_lookup_bytype => returns 0
> xfrm_policy_lookup() => sets obj to NULL w/ void return
> flow_cache_lookup() => returns NULL
> xfrm_lookup => returns 0
> 
> and the packet proceeds without error and with no transform 
> applied (i.e. 
> leaked as cleartext).

This is indeed the "designed" and expected (for me) behavior. But I am
beginning to see where this is perhaps NOT in line with the user
expectation when the users have an IPSec policy rule that does NOT use
labels.

IOW, if they have their policy like (NO LABELS):

spdadd 192.168.4.79 192.168.4.78 any -P out ipsec
        esp/transport//require;

spdadd 192.168.4.78 192.168.4.79 any -P in ipsec
        esp/transport//require;

currently, EACH flow needing to use this rule MUST
have SELinux policy "polmatch"ing the flow context (ftpd_t)
to unlabeled_t (the implied in the absence of an explicit
context on the IPSec policy rule) or the traffic would flow
in clear text ("leaks" in user perception).

What I propose we do is to do the polmatch check ONLY when
there's an explicit label associated with the spd rule. Does
this sound reasonable and correct in the larger SELinux context?

In cases where there's an explicit label on an spd rule like:

spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
	-P out ipsec
        esp/transport//require;

spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
	-P in ipsec
        esp/transport//require;

then the current behavior (prior to this proposed patch) would be the
desired behavior, i.e., a polmatch denial in the SELinux module just
means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
no need to propagate -EACCES all the way back up. We could still propagate
errors other than -EACCES if we like.

> 
> The first component of the fix is to propagate errors back up 
> to callers 
> via the flow cache resolver, and handle them correctly, as 
> this is where 
> we can experience security module denials.

This will cause problems with the case where we may have multiple
"labeled" spd rules, each of which should be attempted to be polmatched
against before letting the flow out in clear text, as would be expected
by the user as well.

> 
> The second component is to then ensure that, on failure,

-EACCES in this case is perceived as a failure since the
designed behavior doesn't seem to be in line with the user
expectation. Otherwise, with the above proposed change to
the design, there won't be a polmatch check in this case and
hence no failure.

It's probably still a good idea to propagate non-EACCES failures
back up the chain though.

> we 
> kill the new 
> flow cache entry created during lookup, so that it is not 
> subsequently 
> looked up with a null policy (i.e. allowing future packets to 
> leak) and to 
> force the security hook to be called again in case the policy 
> has changed.  
> 
> Hope that clarifies.
>     
> 
> - James
> -- 
> James Morris
> <jmorris@namei.org>
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH] Fix for IPsec leakage with SELinux enabled
  2006-10-02 17:09 [PATCH] Fix for IPsec leakage with SELinux enabled Venkat Yekkirala
@ 2006-10-02 18:39 ` James Morris
  0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2006-10-02 18:39 UTC (permalink / raw)
  To: Venkat Yekkirala
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Evgeniy Polyakov, Paul Moore, Chad Hanson

On Mon, 2 Oct 2006, Venkat Yekkirala wrote:

> This is indeed the "designed" and expected (for me) behavior.

This is a security hole.  SELinux denies all access by default, so the 
default behavior of this code is to allow all traffic to bypass IPsec.

You should not need to add a rule to 'allow' increased security.

> But I am
> beginning to see where this is perhaps NOT in line with the user
> expectation when the users have an IPSec policy rule that does NOT use
> labels.
> currently, EACH flow needing to use this rule MUST
> have SELinux policy "polmatch"ing the flow context (ftpd_t)
> to unlabeled_t (the implied in the absence of an explicit
> context on the IPSec policy rule) or the traffic would flow
> in clear text ("leaks" in user perception).

Plaintext leak is not a user perception, it's an absolute.

> What I propose we do is to do the polmatch check ONLY when
> there's an explicit label associated with the spd rule. Does
> this sound reasonable and correct in the larger SELinux context?

I think so.

> In cases where there's an explicit label on an spd rule like:
> 
> spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> 	-P out ipsec
>         esp/transport//require;
> 
> spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> 	-P in ipsec
>         esp/transport//require;
> 
> then the current behavior (prior to this proposed patch) would be the
> desired behavior, i.e., a polmatch denial in the SELinux module just
> means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
> no need to propagate -EACCES all the way back up. We could still propagate
> errors other than -EACCES if we like.

This needs to be handled within SELinux as far as possible, and errors 
will generally need to be propagated back to the callers, as we don't know 
what other LSMs might do, and errors unrelated to access control can be 
returned.


- James
-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH] Fix for IPsec leakage with SELinux enabled
@ 2006-10-02 18:59 Venkat Yekkirala
  0 siblings, 0 replies; 10+ messages in thread
From: Venkat Yekkirala @ 2006-10-02 18:59 UTC (permalink / raw)
  To: James Morris, Venkat Yekkirala
  Cc: David S. Miller, Herbert Xu, netdev, Stephen Smalley,
	Evgeniy Polyakov, Paul Moore, Chad Hanson

> > This is indeed the "designed" and expected (for me) behavior.
> 
> This is a security hole.  SELinux denies all access by 
> default, so the 
> default behavior of this code is to allow all traffic to bypass IPsec.
> 
> You should not need to add a rule to 'allow' increased security.

You are right. Currently working on a patch (should be out
tonight/tomorrow).

<snip>

> This needs to be handled within SELinux as far as possible, 
> and errors 
> will generally need to be propagated back to the callers, as 

Agreed here as well. I have yet to review your patch in depth,
but it definitely makes sense to do what you say here. Thanks.

> we don't know 
> what other LSMs might do, and errors unrelated to access 
> control can be 
> returned.
> 
> 
> - James
> -- 
> James Morris
> <jmorris@namei.org>
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2006-10-02 19:00 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-02 17:09 [PATCH] Fix for IPsec leakage with SELinux enabled Venkat Yekkirala
2006-10-02 18:39 ` James Morris
  -- strict thread matches above, loose matches on Subject: below --
2006-10-02 18:59 Venkat Yekkirala
2006-10-01 20:55 Venkat Yekkirala
2006-10-02  1:44 ` James Morris
2006-09-24 14:33 Is TCP over IPsec broken in 2.6.18? James Morris
2006-09-24 23:54 ` Herbert Xu
     [not found]   ` <20060925103836.GA13966@2ka.mipt.ru>
2006-09-25 11:27     ` Herbert Xu
2006-09-25 12:05       ` Evgeniy Polyakov
2006-09-30  5:06         ` James Morris
2006-09-30  5:14           ` James Morris
2006-09-30 11:15             ` Evgeniy Polyakov
2006-09-30 14:36               ` James Morris
2006-09-30 14:40                 ` Evgeniy Polyakov
2006-09-30 14:44                   ` James Morris
2006-10-01  6:27                     ` [PATCH] Fix for IPsec leakage with SELinux enabled James Morris
2006-10-02 11:20                       ` Evgeniy Polyakov
2006-10-02 13:31                         ` James Morris
2006-10-02 13:42                           ` Evgeniy Polyakov
2006-10-02 14:05                             ` James Morris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).