On Sun, Oct 01, 2006 at 02:27:13AM -0400, James Morris ([EMAIL PROTECTED])
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
-
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
