1. 12 Oct, 2006 9 commits
    • Miklos Szeredi's avatar
      [NET]: File descriptor loss while receiving SCM_RIGHTS · effee6a0
      Miklos Szeredi authored
      If more than one file descriptor was sent with an SCM_RIGHTS message,
      and on the receiving end, after installing a nonzero (but not all)
      file descritpors the process runs out of fds, then the already
      installed fds will be lost (userspace will have no way of knowing
      about them).
      
      The following patch makes sure, that at least the already installed
      fds are sent to userspace.  It doesn't solve the issue of losing file
      descriptors in case of an EFAULT on the userspace buffer.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      effee6a0
    • Vlad Yasevich's avatar
      [SCTP]: Fix the RX queue size shown in /proc/net/sctp/assocs output. · 6aa2551c
      Vlad Yasevich authored
      Show the true receive buffer usage.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6aa2551c
    • Vlad Yasevich's avatar
      [SCTP]: Fix receive buffer accounting. · 331c4ee7
      Vlad Yasevich authored
      When doing receiver buffer accounting, we always used skb->truesize.
      This is problematic when processing bundled DATA chunks because for
      every DATA chunk that could be small part of one large skb, we would
      charge the size of the entire skb.  The new approach is to store the
      size of the DATA chunk we are accounting for in the sctp_ulpevent
      structure and use that stored value for accounting.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      331c4ee7
    • Chad Sellers's avatar
      SELinux: Bug fix in polidydb_destroy · 6e8c751e
      Chad Sellers authored
      This patch fixes two bugs in policydb_destroy. Two list pointers
      (policydb.ocontexts[i] and policydb.genfs) were not being reset to NULL when
      the lists they pointed to were being freed. This caused a problem when the
      initial policy load failed, as the policydb being destroyed was not a
      temporary new policydb that was thrown away, but rather was the global
      (active) policydb. Consequently, later functions, particularly
      sys_bind->selinux_socket_bind->security_node_sid and
      do_rw_proc->selinux_sysctl->selinux_proc_get_sid->security_genfs_sid tried
      to dereference memory that had previously been freed.
      Signed-off-by: default avatarChad Sellers <csellers@tresys.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      6e8c751e
    • Venkat Yekkirala's avatar
      IPsec: fix handling of errors for socket policies · 3bccfbc7
      Venkat Yekkirala authored
      This treats the security errors encountered in the case of
      socket policy matching, the same as how these are treated in
      the case of main/sub policies, which is to return a full lookup
      failure.
      Signed-off-by: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      3bccfbc7
    • Venkat Yekkirala's avatar
      IPsec: correct semantics for SELinux policy matching · 5b368e61
      Venkat Yekkirala authored
      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: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      5b368e61
    • James Morris's avatar
      IPsec: propagate security module errors up from flow_cache_lookup · 134b0fc5
      James Morris authored
      When a security module is loaded (in this case, SELinux), the
      security_xfrm_policy_lookup() hook can return an access denied permission
      (or other error).  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 way I 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.
      
      The first SYNACK would be blocked, because of an uncached lookup via
      flow_cache_lookup(), which would fail to resolve an xfrm policy because
      the SELinux policy is checked at that point via the resolver.
      
      However, retransmitted SYNACKs would then find a cached flow entry when
      calling into flow_cache_lookup() with a null xfrm policy, which is
      interpreted by xfrm_lookup() as the packet not having any associated
      policy and similarly to the first case, allowing it to pass without
      transformation.
      
      The solution presented here 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).
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      134b0fc5
    • paul.moore@hp.com's avatar
      NetLabel: use SECINITSID_UNLABELED for a base SID · 388b2405
      paul.moore@hp.com authored
      This patch changes NetLabel to use SECINITSID_UNLABLELED as it's source of
      SELinux type information when generating a NetLabel context.
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      388b2405
    • paul.moore@hp.com's avatar
      NetLabel: fix a cache race condition · ffb733c6
      paul.moore@hp.com authored
      Testing revealed a problem with the NetLabel cache where a cached entry could
      be freed while in use by the LSM layer causing an oops and other problems.
      This patch fixes that problem by introducing a reference counter to the cache
      entry so that it is only freed when it is no longer in use.
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      ffb733c6
  2. 11 Oct, 2006 31 commits