An error occurred fetching the project authors.
  1. 08 Feb, 2007 2 commits
  2. 24 Jan, 2007 1 commit
  3. 07 Dec, 2006 4 commits
  4. 03 Dec, 2006 3 commits
  5. 22 Nov, 2006 1 commit
  6. 12 Oct, 2006 3 commits
    • Venkat Yekkirala's avatar
      IPsec: fix handling of errors for socket policies · 3bccfbc7
      Venkat Yekkirala authored
      This treats the security errors encountered in the case of
      socket policy matching, the same as how these are treated in
      the case of main/sub policies, which is to return a full lookup
      failure.
      Signed-off-by: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      3bccfbc7
    • Venkat Yekkirala's avatar
      IPsec: correct semantics for SELinux policy matching · 5b368e61
      Venkat Yekkirala authored
      Currently when an IPSec policy rule doesn't specify a security
      context, it is assumed to be "unlabeled" by SELinux, and so
      the IPSec policy rule fails to match to a flow that it would
      otherwise match to, unless one has explicitly added an SELinux
      policy rule allowing the flow to "polmatch" to the "unlabeled"
      IPSec policy rules. In the absence of such an explicitly added
      SELinux policy rule, the IPSec policy rule fails to match and
      so the packet(s) flow in clear text without the otherwise applicable
      xfrm(s) applied.
      
      The above SELinux behavior violates the SELinux security notion of
      "deny by default" which should actually translate to "encrypt by
      default" in the above case.
      
      This was first reported by Evgeniy Polyakov and the way James Morris
      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.
      
      With this patch applied, SELinux "polmatching" of flows Vs. IPSec
      policy rules will only come into play when there's a explicit context
      specified for the IPSec policy rule (which also means there's corresponding
      SELinux policy allowing appropriate domains/flows to polmatch to this context).
      
      Secondly, when a security module is loaded (in this case, SELinux), the
      security_xfrm_policy_lookup() hook can return errors other than access denied,
      such as -EINVAL.  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 solution for this 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).
      
      This patch: Fix the selinux side of things.
      
      This makes sure SELinux polmatching of flow contexts to IPSec policy
      rules comes into play only when an explicit context is associated
      with the IPSec policy rule.
      
      Also, this no longer defaults the context of a socket policy to
      the context of the socket since the "no explicit context" case
      is now handled properly.
      Signed-off-by: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      5b368e61
    • 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
  7. 04 Oct, 2006 1 commit
  8. 22 Sep, 2006 18 commits
  9. 14 Aug, 2006 1 commit
    • David S. Miller's avatar
      [IPSEC]: Validate properly in xfrm_dst_check() · d49c73c7
      David S. Miller authored
      If dst->obsolete is -1, this is a signal from the
      bundle creator that we want the XFRM dst and the
      dsts that it references to be validated on every
      use.
      
      I misunderstood this intention when I changed
      xfrm_dst_check() to always return NULL.
      
      Now, when we purge a dst entry, by running dst_free()
      on it.  This will set the dst->obsolete to a positive
      integer, and we want to return NULL in that case so
      that the socket does a relookup for the route.
      
      Thus, if dst->obsolete<0, let stale_bundle() validate
      the state, else always return NULL.
      
      In general, we need to do things more intelligently
      here because we flush too much state during rule
      changes.  Herbert Xu has some ideas wherein the key
      manager gives us some help in this area.  We can also
      use smarter state management algorithms inside of
      the kernel as well.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d49c73c7
  10. 21 Jul, 2006 1 commit
  11. 30 Jun, 2006 1 commit
  12. 18 Jun, 2006 2 commits
    • Herbert Xu's avatar
      [IPSEC] xfrm: Abstract out encapsulation modes · b59f45d0
      Herbert Xu authored
      This patch adds the structure xfrm_mode.  It is meant to represent
      the operations carried out by transport/tunnel modes.
      
      By doing this we allow additional encapsulation modes to be added
      without clogging up the xfrm_input/xfrm_output paths.
      
      Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
      BEET modes.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b59f45d0
    • Herbert Xu's avatar
      [IPSEC] xfrm: Undo afinfo lock proliferation · 546be240
      Herbert Xu authored
      The number of locks used to manage afinfo structures can easily be reduced
      down to one each for policy and state respectively.  This is based on the
      observation that the write locks are only held by module insertion/removal
      which are very rare events so there is no need to further differentiate
      between the insertion of modules like ipv6 versus esp6.
      
      The removal of the read locks in xfrm4_policy.c/xfrm6_policy.c might look
      suspicious at first.  However, after you realise that nobody ever takes
      the corresponding write lock you'll feel better :)
      
      As far as I can gather it's an attempt to guard against the removal of
      the corresponding modules.  Since neither module can be unloaded at all
      we can leave it to whoever fixes up IPv6 unloading :)
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      546be240
  13. 30 Apr, 2006 2 commits
    • Ingo Molnar's avatar
      [XFRM]: fix incorrect xfrm_policy_afinfo_lock use · e959d812
      Ingo Molnar authored
      xfrm_policy_afinfo_lock can be taken in bh context, at:
      
       [<c013fe1a>] lockdep_acquire_read+0x54/0x6d
       [<c0f6e024>] _read_lock+0x15/0x22
       [<c0e8fcdb>] xfrm_policy_get_afinfo+0x1a/0x3d
       [<c0e8fd10>] xfrm_decode_session+0x12/0x32
       [<c0e66094>] ip_route_me_harder+0x1c9/0x25b
       [<c0e770d3>] ip_nat_local_fn+0x94/0xad
       [<c0e2bbc8>] nf_iterate+0x2e/0x7a
       [<c0e2bc50>] nf_hook_slow+0x3c/0x9e
       [<c0e3a342>] ip_push_pending_frames+0x2de/0x3a7
       [<c0e53e19>] icmp_push_reply+0x136/0x141
       [<c0e543fb>] icmp_reply+0x118/0x1a0
       [<c0e54581>] icmp_echo+0x44/0x46
       [<c0e53fad>] icmp_rcv+0x111/0x138
       [<c0e36764>] ip_local_deliver+0x150/0x1f9
       [<c0e36be2>] ip_rcv+0x3d5/0x413
       [<c0df760f>] netif_receive_skb+0x337/0x356
       [<c0df76c3>] process_backlog+0x95/0x110
       [<c0df5fe2>] net_rx_action+0xa5/0x16d
       [<c012d8a7>] __do_softirq+0x6f/0xe6
       [<c0105ec2>] do_softirq+0x52/0xb1
      
      this means that all write-locking of xfrm_policy_afinfo_lock must be
      bh-safe. This patch fixes xfrm_policy_register_afinfo() and
      xfrm_policy_unregister_afinfo().
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e959d812
    • Ingo Molnar's avatar
      [XFRM]: fix softirq-unsafe xfrm typemap->lock use · 8dff7c29
      Ingo Molnar authored
      xfrm typemap->lock may be used in softirq context, so all write_lock()
      uses must be softirq-safe.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dff7c29