1. 07 1月, 2006 6 次提交
  2. 04 1月, 2006 2 次提交
    • T
      [LSM-IPSec]: Per-packet access control. · d28d1e08
      Trent Jaeger 提交于
      This patch series implements per packet access control via the
      extension of the Linux Security Modules (LSM) interface by hooks in
      the XFRM and pfkey subsystems that leverage IPSec security
      associations to label packets.  Extensions to the SELinux LSM are
      included that leverage the patch for this purpose.
      
      This patch implements the changes necessary to the SELinux LSM to
      create, deallocate, and use security contexts for policies
      (xfrm_policy) and security associations (xfrm_state) that enable
      control of a socket's ability to send and receive packets.
      
      Patch purpose:
      
      The patch is designed to enable the SELinux LSM to implement access
      control on individual packets based on the strongly authenticated
      IPSec security association.  Such access controls augment the existing
      ones in SELinux based on network interface and IP address.  The former
      are very coarse-grained, and the latter can be spoofed.  By using
      IPSec, the SELinux can control access to remote hosts based on
      cryptographic keys generated using the IPSec mechanism.  This enables
      access control on a per-machine basis or per-application if the remote
      machine is running the same mechanism and trusted to enforce the
      access control policy.
      
      Patch design approach:
      
      The patch's main function is to authorize a socket's access to a IPSec
      policy based on their security contexts.  Since the communication is
      implemented by a security association, the patch ensures that the
      security association's negotiated and used have the same security
      context.  The patch enables allocation and deallocation of such
      security contexts for policies and security associations.  It also
      enables copying of the security context when policies are cloned.
      Lastly, the patch ensures that packets that are sent without using a
      IPSec security assocation with a security context are allowed to be
      sent in that manner.
      
      A presentation available at
      www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
      from the SELinux symposium describes the overall approach.
      
      Patch implementation details:
      
      The function which authorizes a socket to perform a requested
      operation (send/receive) on a IPSec policy (xfrm_policy) is
      selinux_xfrm_policy_lookup.  The Netfilter and rcv_skb hooks ensure
      that if a IPSec SA with a securit y association has not been used,
      then the socket is allowed to send or receive the packet,
      respectively.
      
      The patch implements SELinux function for allocating security contexts
      when policies (xfrm_policy) are created via the pfkey or xfrm_user
      interfaces via selinux_xfrm_policy_alloc.  When a security association
      is built, SELinux allocates the security context designated by the
      XFRM subsystem which is based on that of the authorized policy via
      selinux_xfrm_state_alloc.
      
      When a xfrm_policy is cloned, the security context of that policy, if
      any, is copied to the clone via selinux_xfrm_policy_clone.
      
      When a xfrm_policy or xfrm_state is freed, its security context, if
      any is also freed at selinux_xfrm_policy_free or
      selinux_xfrm_state_free.
      
      Testing:
      
      The SELinux authorization function is tested using ipsec-tools.  We
      created policies and security associations with particular security
      contexts and added SELinux access control policy entries to verify the
      authorization decision.  We also made sure that packets for which no
      security context was supplied (which either did or did not use
      security associations) were authorized using an unlabelled context.
      Signed-off-by: NTrent Jaeger <tjaeger@cse.psu.edu>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d28d1e08
    • T
      [LSM-IPSec]: Security association restriction. · df71837d
      Trent Jaeger 提交于
      This patch series implements per packet access control via the
      extension of the Linux Security Modules (LSM) interface by hooks in
      the XFRM and pfkey subsystems that leverage IPSec security
      associations to label packets.  Extensions to the SELinux LSM are
      included that leverage the patch for this purpose.
      
      This patch implements the changes necessary to the XFRM subsystem,
      pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
      socket to use only authorized security associations (or no security
      association) to send/receive network packets.
      
      Patch purpose:
      
      The patch is designed to enable access control per packets based on
      the strongly authenticated IPSec security association.  Such access
      controls augment the existing ones based on network interface and IP
      address.  The former are very coarse-grained, and the latter can be
      spoofed.  By using IPSec, the system can control access to remote
      hosts based on cryptographic keys generated using the IPSec mechanism.
      This enables access control on a per-machine basis or per-application
      if the remote machine is running the same mechanism and trusted to
      enforce the access control policy.
      
      Patch design approach:
      
      The overall approach is that policy (xfrm_policy) entries set by
      user-level programs (e.g., setkey for ipsec-tools) are extended with a
      security context that is used at policy selection time in the XFRM
      subsystem to restrict the sockets that can send/receive packets via
      security associations (xfrm_states) that are built from those
      policies.
      
      A presentation available at
      www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
      from the SELinux symposium describes the overall approach.
      
      Patch implementation details:
      
      On output, the policy retrieved (via xfrm_policy_lookup or
      xfrm_sk_policy_lookup) must be authorized for the security context of
      the socket and the same security context is required for resultant
      security association (retrieved or negotiated via racoon in
      ipsec-tools).  This is enforced in xfrm_state_find.
      
      On input, the policy retrieved must also be authorized for the socket
      (at __xfrm_policy_check), and the security context of the policy must
      also match the security association being used.
      
      The patch has virtually no impact on packets that do not use IPSec.
      The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
      before.
      
      Also, if IPSec is used without security contexts, the impact is
      minimal.  The LSM must allow such policies to be selected for the
      combination of socket and remote machine, but subsequent IPSec
      processing proceeds as in the original case.
      
      Testing:
      
      The pfkey interface is tested using the ipsec-tools.  ipsec-tools have
      been modified (a separate ipsec-tools patch is available for version
      0.5) that supports assignment of xfrm_policy entries and security
      associations with security contexts via setkey and the negotiation
      using the security contexts via racoon.
      
      The xfrm_user interface is tested via ad hoc programs that set
      security contexts.  These programs are also available from me, and
      contain programs for setting, getting, and deleting policy for testing
      this interface.  Testing of sa functions was done by tracing kernel
      behavior.
      Signed-off-by: NTrent Jaeger <tjaeger@cse.psu.edu>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df71837d
  3. 02 12月, 2005 1 次提交
  4. 09 11月, 2005 3 次提交
  5. 07 11月, 2005 2 次提交
  6. 31 10月, 2005 9 次提交
  7. 28 10月, 2005 1 次提交
  8. 24 10月, 2005 2 次提交
  9. 09 10月, 2005 4 次提交
  10. 01 10月, 2005 1 次提交
    • J
      [PATCH] SELinux - fix SCTP socket bug and general IP protocol handling · 13402580
      James Morris 提交于
      The following patch updates the way SELinux classifies and handles IP
      based protocols.
      
      Currently, IP sockets are classified by SELinux as being either TCP, UDP
      or 'Raw', the latter being a default for IP socket that is not TCP or UDP.
      
      The classification code is out of date and uses only the socket type
      parameter to socket(2) to determine the class of IP socket.  So, any
      socket created with SOCK_STREAM will be classified by SELinux as TCP, and
      SOCK_DGRAM as UDP.  Also, other socket types such as SOCK_SEQPACKET and
      SOCK_DCCP are currently ignored by SELinux, which classifies them as
      generic sockets, which means they don't even get basic IP level checking.
      
      This patch changes the SELinux IP socket classification logic, so that
      only an IPPROTO_IP protocol value passed to socket(2) classify the socket
      as TCP or UDP.  The patch also drops the check for SOCK_RAW and converts
      it into a default, so that socket types like SOCK_DCCP and SOCK_SEQPACKET
      are classified as SECCLASS_RAWIP_SOCKET (instead of generic sockets).
      
      Note that protocol-specific support for SCTP, DCCP etc. is not addressed
      here, we're just getting these protocols checked at the IP layer.
      
      This fixes a reported problem where SCTP sockets were being recognized as
      generic SELinux sockets yet still being passed in one case to an IP level
      check, which then fails for generic sockets.
      
      It will also fix bugs where any SOCK_STREAM socket is classified as TCP or
      any SOCK_DGRAM socket is classified as UDP.
      
      This patch also unifies the way IP sockets classes are determined in
      selinux_socket_bind(), so we use the already calculated value instead of
      trying to recalculate it.
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      13402580
  11. 29 9月, 2005 1 次提交
    • D
      [PATCH] Keys: Add possessor permissions to keys [try #3] · 664cceb0
      David Howells 提交于
      The attached patch adds extra permission grants to keys for the possessor of a
      key in addition to the owner, group and other permissions bits. This makes
      SUID binaries easier to support without going as far as labelling keys and key
      targets using the LSM facilities.
      
      This patch adds a second "pointer type" to key structures (struct key_ref *)
      that can have the bottom bit of the address set to indicate the possession of
      a key. This is propagated through searches from the keyring to the discovered
      key. It has been made a separate type so that the compiler can spot attempts
      to dereference a potentially incorrect pointer.
      
      The "possession" attribute can't be attached to a key structure directly as
      it's not an intrinsic property of a key.
      
      Pointers to keys have been replaced with struct key_ref *'s wherever
      possession information needs to be passed through.
      
      This does assume that the bottom bit of the pointer will always be zero on
      return from kmem_cache_alloc().
      
      The key reference type has been made into a typedef so that at least it can be
      located in the sources, even though it's basically a pointer to an undefined
      type. I've also renamed the accessor functions to be more useful, and all
      reference variables should now end in "_ref".
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      664cceb0
  12. 18 9月, 2005 2 次提交
  13. 10 9月, 2005 6 次提交