1. 04 1月, 2006 1 次提交
    • 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