• James Morris's avatar
    IPsec: propagate security module errors up from flow_cache_lookup · 134b0fc5
    James Morris authored
    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).
    Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    134b0fc5
xfrm_policy.c 47.6 KB