1. 22 11月, 2006 3 次提交
  2. 16 11月, 2006 2 次提交
  3. 06 11月, 2006 2 次提交
  4. 02 11月, 2006 1 次提交
  5. 31 10月, 2006 6 次提交
  6. 25 10月, 2006 2 次提交
    • P
      [NETFILTER]: Fix ip6_tables extension header bypass bug · 6d381634
      Patrick McHardy 提交于
      As reported by Mark Dowd <Mark_Dowd@McAfee.com>, ip6_tables is susceptible
      to a fragmentation attack causing false negatives on extension header matches.
      
      When extension headers occur in the non-first fragment after the fragment
      header (possibly with an incorrect nexthdr value in the fragment header)
      a rule looking for this extension header will never match.
      
      Drop fragments that are at offset 0 and don't contain the final protocol
      header regardless of the ruleset, since this should not happen normally.
      Since all extension headers are before the protocol header this makes sure
      an extension header is either not present or in the first fragment, where
      we can properly parse it.
      
      With help from Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d381634
    • P
      [NETFILTER]: Fix ip6_tables protocol bypass bug · 51d8b1a6
      Patrick McHardy 提交于
      As reported by Mark Dowd <Mark_Dowd@McAfee.com>, ip6_tables is susceptible
      to a fragmentation attack causing false negatives on protocol matches.
      
      When the protocol header doesn't follow the fragment header immediately,
      the fragment header contains the protocol number of the next extension
      header. When the extension header and the protocol header are sent in
      a second fragment a rule like "ip6tables .. -p udp -j DROP" will never
      match.
      
      Drop fragments that are at offset 0 and don't contain the final protocol
      header regardless of the ruleset, since this should not happen normally.
      
      With help from Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51d8b1a6
  7. 22 10月, 2006 1 次提交
  8. 19 10月, 2006 6 次提交
  9. 16 10月, 2006 3 次提交
  10. 12 10月, 2006 5 次提交
    • Y
    • Y
    • J
      [IPV6]: Seperate sit driver to extra module (addrconf.c changes) · 0be669bb
      Joerg Roedel 提交于
      This patch contains the changes to net/ipv6/addrconf.c to remove sit
      specific code if the sit driver is not selected.
      Signed-off-by: NJoerg Roedel <joro-lkml@zlug.org>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0be669bb
    • J
      [IPV6]: Seperate sit driver to extra module · 989e5b96
      Joerg Roedel 提交于
      This patch removes the driver of the IPv6-in-IPv4 tunnel driver (sit)
      from the IPv6 module. It adds an option to Kconfig which makes it
      possible to compile it as a seperate module.
      Signed-off-by: NJoerg Roedel <joro-lkml@zlug.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      989e5b96
    • V
      IPsec: correct semantics for SELinux policy matching · 5b368e61
      Venkat Yekkirala 提交于
      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: NVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      5b368e61
  11. 04 10月, 2006 4 次提交
  12. 29 9月, 2006 5 次提交