Skip to content
  • Trent Jaeger's avatar
    [LSM-IPSec]: Per-packet access control. · d28d1e08
    Trent Jaeger authored
    
    
    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: default avatarTrent Jaeger <tjaeger@cse.psu.edu>
    Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    d28d1e08