1. 29 1月, 2008 2 次提交
  2. 11 12月, 2007 1 次提交
  3. 18 10月, 2007 3 次提交
    • H
      [IPSEC]: Rename mode to outer_mode and add inner_mode · 13996378
      Herbert Xu 提交于
      This patch adds a new field to xfrm states called inner_mode.  The existing
      mode object is renamed to outer_mode.
      
      This is the first part of an attempt to fix inter-family transforms.  As it
      is we always use the outer family when determining which mode to use.  As a
      result we may end up shoving IPv4 packets into netfilter6 and vice versa.
      
      What we really want is to use the inner family for the first part of outbound
      processing and the outer family for the second part.  For inbound processing
      we'd use the opposite pairing.
      
      I've also added a check to prevent silly combinations such as transport mode
      with inter-family transforms.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13996378
    • H
      [IPSEC]: Store afinfo pointer in xfrm_mode · 17c2a42a
      Herbert Xu 提交于
      It is convenient to have a pointer from xfrm_state to address-specific
      functions such as the output function for a family.  Currently the
      address-specific policy code calls out to the xfrm state code to get
      those pointers when we could get it in an easier way via the state
      itself.
      
      This patch adds an xfrm_state_afinfo to xfrm_mode (since they're
      address-specific) and changes the policy code to use it.  I've also
      added an owner field to do reference counting on the module providing
      the afinfo even though it isn't strictly necessary today since IPv6
      can't be unloaded yet.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17c2a42a
    • H
      [IPSEC]: Add missing BEET checks · 1bfcb10f
      Herbert Xu 提交于
      Currently BEET mode does not reinject the packet back into the stack
      like tunnel mode does.  Since BEET should behave just like tunnel mode
      this is incorrect.
      
      This patch fixes this by introducing a flags field to xfrm_mode that
      tells the IPsec code whether it should terminate and reinject the packet
      back into the stack.
      
      It then sets the flag for BEET and tunnel mode.
      
      I've also added a number of missing BEET checks elsewhere where we check
      whether a given mode is a tunnel or not.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bfcb10f
  4. 11 10月, 2007 2 次提交
  5. 11 7月, 2007 1 次提交
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  6. 26 4月, 2007 4 次提交
  7. 27 2月, 2007 1 次提交
  8. 11 2月, 2007 2 次提交
  9. 09 2月, 2007 1 次提交
  10. 03 12月, 2006 2 次提交
    • G
      [NET]: Supporting UDP-Lite (RFC 3828) in Linux · ba4e58ec
      Gerrit Renker 提交于
      This is a revision of the previously submitted patch, which alters
      the way files are organized and compiled in the following manner:
      
      	* UDP and UDP-Lite now use separate object files
      	* source file dependencies resolved via header files
      	  net/ipv{4,6}/udp_impl.h
      	* order of inclusion files in udp.c/udplite.c adapted
      	  accordingly
      
      [NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828)
      
      This patch adds support for UDP-Lite to the IPv4 stack, provided as an
      extension to the existing UDPv4 code:
              * generic routines are all located in net/ipv4/udp.c
              * UDP-Lite specific routines are in net/ipv4/udplite.c
              * MIB/statistics support in /proc/net/snmp and /proc/net/udplite
              * shared API with extensions for partial checksum coverage
      
      [NET/IPv6]: Extension for UDP-Lite over IPv6
      
      It extends the existing UDPv6 code base with support for UDP-Lite
      in the same manner as per UDPv4. In particular,
              * UDPv6 generic and shared code is in net/ipv6/udp.c
              * UDP-Litev6 specific extensions are in net/ipv6/udplite.c
              * MIB/statistics support in /proc/net/snmp6 and /proc/net/udplite6
              * support for IPV6_ADDRFORM
              * aligned the coding style of protocol initialisation with af_inet6.c
              * made the error handling in udpv6_queue_rcv_skb consistent;
                to return `-1' on error on all error cases
              * consolidation of shared code
      
      [NET]: UDP-Lite Documentation and basic XFRM/Netfilter support
      
      The UDP-Lite patch further provides
              * API documentation for UDP-Lite
              * basic xfrm support
              * basic netfilter support for IPv4 and IPv6 (LOG target)
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba4e58ec
    • A
      [XFRM]: misc annotations · 8c689a6e
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c689a6e
  11. 19 10月, 2006 1 次提交
  12. 12 10月, 2006 1 次提交
    • 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
  13. 23 9月, 2006 7 次提交
  14. 01 7月, 2006 1 次提交
  15. 18 6月, 2006 1 次提交
    • H
      [IPSEC] xfrm: Undo afinfo lock proliferation · 546be240
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      546be240
  16. 19 4月, 2006 2 次提交
  17. 08 2月, 2006 1 次提交
  18. 20 12月, 2005 1 次提交
  19. 27 5月, 2005 1 次提交
  20. 04 5月, 2005 1 次提交
    • H
      [IPSEC]: Store idev entries · aabc9761
      Herbert Xu 提交于
      I found a bug that stopped IPsec/IPv6 from working.  About
      a month ago IPv6 started using rt6i_idev->dev on the cached socket dst
      entries.  If the cached socket dst entry is IPsec, then rt6i_idev will
      be NULL.
      
      Since we want to look at the rt6i_idev of the original route in this
      case, the easiest fix is to store rt6i_idev in the IPsec dst entry just
      as we do for a number of other IPv6 route attributes.  Unfortunately
      this means that we need some new code to handle the references to
      rt6i_idev.  That's why this patch is bigger than it would otherwise be.
      
      I've also done the same thing for IPv4 since it is conceivable that
      once these idev attributes start getting used for accounting, we
      probably need to dereference them for IPv4 IPsec entries too.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aabc9761
  21. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4