1. 11 10月, 2007 2 次提交
  2. 31 7月, 2007 1 次提交
  3. 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
  4. 05 5月, 2007 2 次提交
  5. 29 4月, 2007 1 次提交
  6. 27 4月, 2007 1 次提交
  7. 26 4月, 2007 9 次提交
  8. 14 4月, 2007 1 次提交
    • J
      [IPSEC] XFRM_USER: kernel panic when large security contexts in ACQUIRE · 661697f7
      Joy Latten 提交于
      When sending a security context of 50+ characters in an ACQUIRE 
      message, following kernel panic occurred.
      
      kernel BUG in xfrm_send_acquire at net/xfrm/xfrm_user.c:1781!
      cpu 0x3: Vector: 700 (Program Check) at [c0000000421bb2e0]
          pc: c00000000033b074: .xfrm_send_acquire+0x240/0x2c8
          lr: c00000000033b014: .xfrm_send_acquire+0x1e0/0x2c8
          sp: c0000000421bb560
         msr: 8000000000029032
        current = 0xc00000000fce8f00
        paca    = 0xc000000000464b00
          pid   = 2303, comm = ping
      kernel BUG in xfrm_send_acquire at net/xfrm/xfrm_user.c:1781!
      enter ? for help
      3:mon> t
      [c0000000421bb650] c00000000033538c .km_query+0x6c/0xec
      [c0000000421bb6f0] c000000000337374 .xfrm_state_find+0x7f4/0xb88
      [c0000000421bb7f0] c000000000332350 .xfrm_tmpl_resolve+0xc4/0x21c
      [c0000000421bb8d0] c0000000003326e8 .xfrm_lookup+0x1a0/0x5b0
      [c0000000421bba00] c0000000002e6ea0 .ip_route_output_flow+0x88/0xb4
      [c0000000421bbaa0] c0000000003106d8 .ip4_datagram_connect+0x218/0x374
      [c0000000421bbbd0] c00000000031bc00 .inet_dgram_connect+0xac/0xd4
      [c0000000421bbc60] c0000000002b11ac .sys_connect+0xd8/0x120
      [c0000000421bbd90] c0000000002d38d0 .compat_sys_socketcall+0xdc/0x214
      [c0000000421bbe30] c00000000000869c syscall_exit+0x0/0x40
      --- Exception: c00 (System Call) at 0000000007f0ca9c
      SP (fc0ef8f0) is in userspace
      
      We are using size of security context from xfrm_policy to determine
      how much space to alloc skb and then putting security context from
      xfrm_state into skb. Should have been using size of security context 
      from xfrm_state to alloc skb. Following fix does that
      Signed-off-by: NJoy Latten <latten@austin.ibm.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      661697f7
  9. 23 3月, 2007 1 次提交
  10. 08 3月, 2007 2 次提交
    • E
      [IPSEC]: xfrm audit hook misplaced in pfkey_delete and xfrm_del_sa · 16bec31d
      Eric Paris 提交于
      Inside pfkey_delete and xfrm_del_sa the audit hooks were not called if
      there was any permission/security failures in attempting to do the del
      operation (such as permission denied from security_xfrm_state_delete).
      This patch moves the audit hook to the exit path such that all failures
      (and successes) will actually get audited.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NVenkat Yekkirala <vyekkirala@trustedcs.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16bec31d
    • E
      [IPSEC]: xfrm_policy delete security check misplaced · ef41aaa0
      Eric Paris 提交于
      The security hooks to check permissions to remove an xfrm_policy were
      actually done after the policy was removed.  Since the unlinking and
      deletion are done in xfrm_policy_by* functions this moves the hooks
      inside those 2 functions.  There we have all the information needed to
      do the security check and it can be done before the deletion.  Since
      auditing requires the result of that security check err has to be passed
      back and forth from the xfrm_policy_by* functions.
      
      This patch also fixes a bug where a deletion that failed the security
      check could cause improper accounting on the xfrm_policy
      (xfrm_get_policy didn't have a put on the exit path for the hold taken
      by xfrm_policy_by*)
      
      It also fixes the return code when no policy is found in
      xfrm_add_pol_expire.  In old code (at least back in the 2.6.18 days) err
      wasn't used before the return when no policy is found and so the
      initialization would cause err to be ENOENT.  But since err has since
      been used above when we don't get a policy back from the xfrm_policy_by*
      function we would always return 0 instead of the intended ENOENT.  Also
      fixed some white space damage in the same area.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NVenkat Yekkirala <vyekkirala@trustedcs.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef41aaa0
  11. 01 3月, 2007 2 次提交
  12. 13 2月, 2007 1 次提交
  13. 11 2月, 2007 1 次提交
  14. 09 2月, 2007 1 次提交
  15. 04 1月, 2007 1 次提交
  16. 07 12月, 2006 1 次提交
  17. 04 12月, 2006 1 次提交
  18. 03 12月, 2006 7 次提交
  19. 26 11月, 2006 1 次提交
  20. 22 11月, 2006 2 次提交
  21. 31 10月, 2006 1 次提交