Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 5月, 2007 1 次提交
  3. 29 4月, 2007 1 次提交
  5. 27 4月, 2007 1 次提交
  7. 26 4月, 2007 9 次提交
  9. 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
  11. 23 3月, 2007 1 次提交
  13. 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
  15. 01 3月, 2007 2 次提交
  17. 13 2月, 2007 1 次提交
  19. 11 2月, 2007 1 次提交
  21. 09 2月, 2007 1 次提交
  23. 04 1月, 2007 1 次提交
  25. 07 12月, 2006 1 次提交
  27. 04 12月, 2006 1 次提交
  29. 03 12月, 2006 7 次提交
  31. 26 11月, 2006 1 次提交
  33. 22 11月, 2006 2 次提交
  35. 31 10月, 2006 1 次提交
  37. 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
  39. 04 10月, 2006 1 次提交
  41. 23 9月, 2006 3 次提交