1. 27 2月, 2007 1 次提交
  2. 11 2月, 2007 2 次提交
  3. 09 2月, 2007 1 次提交
  4. 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
  5. 19 10月, 2006 1 次提交
  6. 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
  7. 23 9月, 2006 7 次提交
  8. 01 7月, 2006 1 次提交
  9. 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
  10. 19 4月, 2006 2 次提交
  11. 08 2月, 2006 1 次提交
  12. 20 12月, 2005 1 次提交
  13. 27 5月, 2005 1 次提交
  14. 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
  15. 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