aboutsummaryrefslogtreecommitdiffstats
path: root/security/selinux/include/xfrm.h
diff options
context:
space:
mode:
authorJames Morris <jmorris@namei.org>2006-10-05 15:42:27 -0500
committerDavid S. Miller <davem@sunset.davemloft.net>2006-10-11 23:59:34 -0700
commit134b0fc544ba062498451611cb6f3e4454221b3d (patch)
tree84120e405d2bc7112b971fc82b718ae23991351b /security/selinux/include/xfrm.h
parent388b24057f90ba109d4bf855006a8809c383eb76 (diff)
downloadkernel_samsung_smdk4412-134b0fc544ba062498451611cb6f3e4454221b3d.zip
kernel_samsung_smdk4412-134b0fc544ba062498451611cb6f3e4454221b3d.tar.gz
kernel_samsung_smdk4412-134b0fc544ba062498451611cb6f3e4454221b3d.tar.bz2
IPsec: propagate security module errors up from flow_cache_lookup
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: James Morris <jmorris@namei.org>
Diffstat (limited to 'security/selinux/include/xfrm.h')
0 files changed, 0 insertions, 0 deletions