[redhat-lspp] [RFC] [SELXFRM 0/4] SELinux/MLS enhancements to IPSec

[Venkat Yekkirala]

This patch set adds/enhances support for SELinux/MLS in handling IPSec
xfrm's. It builds on the work by Trent Jaeger, et al, on the labeling of
IPSec SAs. A policy patch is also included for reference. Patch is relative
to the lspp.34 kernel (http://people.redhat.com/sgrubb/files/lspp).
ipsec-tools 0.6.5 src in FC rawhide already has the setkey changes needed to
work with this. A patch to ipsec-tools/racoon will follow later on the
ipsec-tools-devel list.

The basic idea is to have the IPSec policy specify an MLS range and have
unique SAs generated/used for each of the levels that fall in the range. SAs
for different levels can either be manually loaded (using setkey and such)
or negotiated using IKE (racoon, etc.).

Example:

Let's say we have the following in the SPD (Security Policy Database):

spdadd 9.2.9.15 9.2.9.17 any -ctx 1 1
"system_u:object_r:zzyzx_t:s0-s9:c0-c127"
-P in ipsec esp/transport//require ;
spdadd 9.2.9.17 9.2.9.15 any -ctx 1 1
"system_u:object_r:zzyzx_t:s0-s9:c0-c127"
-P out ipsec esp/transport//require ;

with nothing in the SAD (Security Association Database) initially. When the
kernel runs into the first packet with the label s2:c4 destined for
9.2.9.17, it will see that there's no SA available to encrypt it with. So,
it will call upon racoon/IKE to generate an SA. Racoon will obtain the label
(s2:c4) from the kernel, do the negotiation with its peer, including the
label (s2:c4) also in the payload/proposals. The negotiation will result in
a dynamically generated SPI that is unique to the label (s2:c4) plus the
other normal parameters involved. It will then insert the SA (along with the
SPI) such as the following into the SAD in the kernel:

add 9.2.9.15 9.2.9.17 esp 0x123456
-ctx 1 1 "system_u:object_r:zzyzx_t:s2:c4"
-E des-cbc 0x0000000000000000;

If the kernel subsequently runs into a packet at a different label (say
s2:c5) for which there's no SA available, it will again call upon racoon
(which will get s2:c5 from the kernel this time) and a different SA (with a
different SPI) will be negotiated.

Description of changes:

While the following uses MLS examples and hence may seem MLS-oriented, the
controls would apply equally to SELinux/TE.

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().

Outstanding issues:
- Timewait acknowledgements and such are generated using a NULL socket
resulting in the any_socket sid (SYSTEM_HIGH) to be used.


 include/linux/security.h                     |   97 ++++++++++++--
 include/net/flow.h                           |    5
 net/core/flow.c                              |    7 -
 net/core/sock.c                              |    4
 net/key/af_key.c                             |   24 +++
 net/xfrm/xfrm_policy.c                       |   28 ++--
 net/xfrm/xfrm_state.c                        |   12 +
 net/xfrm/xfrm_user.c                         |    2
 security/dummy.c                             |   23 +++
 security/selinux/hooks.c                     |   27 +++
 security/selinux/include/av_perm_to_string.h |    1
 security/selinux/include/av_permissions.h    |    1
 security/selinux/include/objsec.h            |    1
 security/selinux/include/security.h          |    2
 security/selinux/include/xfrm.h              |    9 +
 security/selinux/ss/mls.c                    |   20 --
 security/selinux/ss/mls.h                    |   20 ++
 security/selinux/ss/services.c               |   48 +++++++
 security/selinux/xfrm.c                      |  185
++++++++++++++++++++++-----
 19 files changed, 423 insertions(+), 93 deletions(-)