• Venkat Yekkirala's avatar
    [MLSXFRM]: Granular IPSec associations for use in MLS environments · 51bd3986
    Venkat Yekkirala authored
    The current approach to labeling Security Associations for SELinux
    purposes uses a one-to-one mapping between xfrm policy rules and
    security associations.
    
    This doesn't address the needs of real world MLS (Multi-level System,
    traditional Bell-LaPadula) environments where a single xfrm policy
    rule (pertaining to a range, classified to secret for example) might
    need to map to multiple Security Associations (one each for
    classified, secret, top secret and all the compartments applicable to
    these security levels).
    
    This patch set addresses the above problem by allowing for the mapping
    of a single xfrm policy rule to multiple security associations, with
    each association used in the security context it is defined for. It
    also includes the security context to be used in IKE negotiation in
    the acquire messages sent to the IKE daemon so that a unique SA can be
    negotiated for each unique security context. A couple of bug fixes are
    also included; checks to make sure the SAs used by a packet match
    policy (security context-wise) on the inbound and also that the bundle
    used for the outbound matches the security context of the flow. This
    patch set also makes the use of the SELinux sid in flow cache lookups
    seemless by including the sid in the flow key itself. Also, open
    requests as well as connection-oriented child sockets are labeled
    automatically to be at the same level as the peer to allow for use of
    appropriately labeled IPSec associations.
    
    Description of changes:
    
    A "sid" member has been added to the flow cache key resulting in the
    sid being available at all needed locations and the flow cache lookups
    automatically using the sid. The flow sid is derived from the socket
    on the outbound and the SAs (unlabeled where an SA was not used) on
    the inbound.
    
    Outbound case:
    1. Find policy for the socket.
    
    2. OLD: Find an SA that matches the policy.
     NEW: Find an SA that matches BOTH the policy and the flow/socket.
       This is necessary since not every SA that matches the policy
       can be used for the flow/socket. Consider policy range Secret-TS,
       and SAs each for Secret and TS. We don't want a TS socket to
       use the Secret SA. Hence the additional check for the SA Vs. flow/socket.
    
    3. NEW: When looking thru bundles for a policy, make sure the
            flow/socket can use the bundle. If a bundle is not found,
            create one, calling for IKE if necessary. If using IKE,
            include the security context in the acquire message to the IKE
            daemon.
    
    Inbound case:
    1. OLD: Find policy for the socket.
     NEW: Find policy for the incoming packet based on the sid of the
          SA(s) it used or the unlabeled sid if no SAs were
          used. (Consider a case where a socket is "authorized" for two
          policies (unclassified-confidential, secret-top_secret). If the
          packet has come in using a secret SA, we really ought to be
          using the latter policy (secret-top_secret).)
    
    2. OLD: BUG: No check to see if the SAs used by the packet agree with
                 the policy sec_ctx-wise.
    
                 (It was indicated in selinux_xfrm_sock_rcv_skb() that
                  this was being accomplished by
                  (x->id.spi == tmpl->id.spi || !tmpl->id.spi) in xfrm_state_ok,
    	      but it turns out tmpl->id.spi
                  would normally be zero (unless xfrm policy rules specify one
                  at the template level, which they usually don't).
     NEW: The socket is checked for access to the SAs used (based on the
          sid of the SAs) in selinux_xfrm_sock_rcv_skb().
    
    Forward case:
     This would be Step 1 from the Inbound case, followed by Steps 2 and 3
    from the Outbound case.
    
    Outstanding items/issues:
    
    - Timewait acknowledgements and such are generated in the
      current/upstream implementation using a NULL socket resulting in the
      any_socket sid (SYSTEM_HIGH) to be used. This problem is not addressed
      by this patch set.
    
    This patch: Add new flask definitions to SELinux
    
    Adds a new avperm "polmatch" to arbitrate flow/state access to a xfrm
    policy rule.
    Signed-off-by: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    51bd3986
av_permissions.h 55.6 KB