1. 27 2月, 2008 1 次提交
  2. 15 2月, 2008 1 次提交
  3. 10 2月, 2008 2 次提交
  4. 02 2月, 2008 1 次提交
  5. 29 1月, 2008 1 次提交
  6. 21 1月, 2008 1 次提交
  7. 20 12月, 2007 1 次提交
    • H
      [IPSEC]: Avoid undefined shift operation when testing algorithm ID · f398035f
      Herbert Xu 提交于
      The aalgos/ealgos fields are only 32 bits wide.  However, af_key tries
      to test them with the expression 1 << id where id can be as large as
      253.  This produces different behaviour on different architectures.
      
      The following patch explicitly checks whether ID is greater than 31
      and fails the check if that's the case.
      
      We cannot easily extend the mask to be longer than 32 bits due to
      exposure to user-space.  Besides, this whole interface is obsolete
      anyway in favour of the xfrm_user interface which doesn't use this
      bit mask in templates (well not within the kernel anyway).
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f398035f
  8. 26 11月, 2007 1 次提交
    • H
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu 提交于
      The change 050f009e
      
      	[IPSEC]: Lock state when copying non-atomic fields to user-space
      
      caused a regression.
      
      Ingo Molnar reports that it causes a potential dead-lock found by the
      lock validator as it tries to take x->lock within xfrm_state_lock while
      numerous other sites take the locks in opposite order.
      
      For 2.6.24, the best fix is to simply remove the added locks as that puts
      us back in the same state as we've been in for years.  For later kernels
      a proper fix would be to reverse the locking order for every xfrm state
      user such that if x->lock is taken together with xfrm_state_lock then
      it is to be taken within it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  9. 22 11月, 2007 1 次提交
  10. 01 11月, 2007 1 次提交
  11. 31 10月, 2007 1 次提交
  12. 11 10月, 2007 6 次提交
    • H
      [IPSEC]: Lock state when copying non-atomic fields to user-space · 050f009e
      Herbert Xu 提交于
      This patch adds locking so that when we're copying non-atomic fields such as
      life-time or coaddr to user-space we don't get a partial result.
      
      For af_key I've changed every instance of pfkey_xfrm_state2msg apart from
      expiration notification to include the keys and life-times.  This is in-line
      with XFRM behaviour.
      
      The actual cases affected are:
      
      * pfkey_getspi: No change as we don't have any keys to copy.
      * key_notify_sa:
      	+ ADD/UPD: This wouldn't work otherwise.
      	+ DEL: It can't hurt.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      050f009e
    • H
      [IPSEC]: Move common code into xfrm_alloc_spi · 658b219e
      Herbert Xu 提交于
      This patch moves some common code that conceptually belongs to the xfrm core
      from af_key/xfrm_user into xfrm_alloc_spi.
      
      In particular, the spin lock on the state is now taken inside xfrm_alloc_spi.
      Previously it also protected the construction of the response PF_KEY/XFRM
      messages to user-space.  This is inconsistent as other identical constructions
      are not protected by the state lock.  This is bad because they in fact should
      be protected but only in certain spots (so as not to hold the lock for too
      long which may cause packet drops).
      
      The SPI byte order conversion has also been moved.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      658b219e
    • E
      [NET]: Make socket creation namespace safe. · 1b8d7ae4
      Eric W. Biederman 提交于
      This patch passes in the namespace a new socket should be created in
      and has the socket code do the appropriate reference counting.  By
      virtue of this all socket create methods are touched.  In addition
      the socket create methods are modified so that they will fail if
      you attempt to create a socket in a non-default network namespace.
      
      Failing if we attempt to create a socket outside of the default
      network namespace ensures that as we incrementally make the network stack
      network namespace aware we will not export functionality that someone
      has not audited and made certain is network namespace safe.
      Allowing us to partially enable network namespaces before all of the
      exotic protocols are supported.
      
      Any protocol layers I have missed will fail to compile because I now
      pass an extra parameter into the socket creation code.
      
      [ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b8d7ae4
    • E
      [NET]: Make /proc/net per network namespace · 457c4cbc
      Eric W. Biederman 提交于
      This patch makes /proc/net per network namespace.  It modifies the global
      variables proc_net and proc_net_stat to be per network namespace.
      The proc_net file helpers are modified to take a network namespace argument,
      and all of their callers are fixed to pass &init_net for that argument.
      This ensures that all of the /proc/net files are only visible and
      usable in the initial network namespace until the code behind them
      has been updated to be handle multiple network namespaces.
      
      Making /proc/net per namespace is necessary as at least some files
      in /proc/net depend upon the set of network devices which is per
      network namespace, and even more files in /proc/net have contents
      that are relevant to a single network namespace.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      457c4cbc
    • J
      [XFRM]: xfrm audit calls · ab5f5e8b
      Joy Latten 提交于
      This patch modifies the current ipsec audit layer
      by breaking it up into purpose driven audit calls.
      
      So far, the only audit calls made are when add/delete
      an SA/policy. It had been discussed to give each
      key manager it's own calls to do this, but I found
      there to be much redundnacy since they did the exact
      same things, except for how they got auid and sid, so I
      combined them. The below audit calls can be made by any
      key manager. Hopefully, this is ok.
      Signed-off-by: NJoy Latten <latten@austin.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab5f5e8b
    • I
      [NET] Cleanup: DIV_ROUND_UP · 356f89e1
      Ilpo Järvinen 提交于
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      356f89e1
  13. 03 8月, 2007 1 次提交
    • J
      [PF_KEY]: Fix ipsec not working in 2.6.23-rc1-git10 · 4a4b6271
      Joy Latten 提交于
      Although an ipsec SA was established, kernel couldn't seem to find it.
      
      I think since we are now using "x->sel.family" instead of "family" in
      the xfrm_selector_match() called in xfrm_state_find(), af_key needs to
      set this field too, just as xfrm_user.
      
      In af_key.c, x->sel.family only gets set when there's an
      ext_hdrs[SADB_EXT_ADDRESS_PROXY-1] which I think is for tunnel.
      
      I think pfkey needs to also set the x->sel.family field when it is 0.
      
      Tested with below patch, and ipsec worked when using pfkey.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a4b6271
  14. 27 7月, 2007 1 次提交
  15. 08 6月, 2007 1 次提交
    • J
      xfrm: Add security check before flushing SAD/SPD · 4aa2e62c
      Joy Latten 提交于
      Currently we check for permission before deleting entries from SAD and
      SPD, (see security_xfrm_policy_delete() security_xfrm_state_delete())
      However we are not checking for authorization when flushing the SPD and
      the SAD completely. It was perhaps missed in the original security hooks
      patch.
      
      This patch adds a security check when flushing entries from the SAD and
      SPD.  It runs the entire database and checks each entry for a denial.
      If the process attempting the flush is unable to remove all of the
      entries a denial is logged the the flush function returns an error
      without removing anything.
      
      This is particularly useful when a process may need to create or delete
      its own xfrm entries used for things like labeled networking but that
      same process should not be able to delete other entries or flush the
      entire database.
      
      Signed-off-by: Joy Latten<latten@austin.ibm.com>
      Signed-off-by: NEric Paris <eparis@parisplace.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      4aa2e62c
  16. 20 5月, 2007 1 次提交
  17. 26 4月, 2007 2 次提交
  18. 19 4月, 2007 1 次提交
  19. 18 4月, 2007 1 次提交
  20. 08 3月, 2007 3 次提交
  21. 13 2月, 2007 1 次提交
  22. 11 2月, 2007 1 次提交
  23. 09 2月, 2007 1 次提交
  24. 07 12月, 2006 1 次提交
  25. 03 12月, 2006 2 次提交
  26. 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
  27. 29 9月, 2006 1 次提交
  28. 23 9月, 2006 3 次提交