[PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[Venkat Yekkirala]

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.

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: Venkat Yekkirala <vyekkirala@TrustedCS.com>
---

The patch set is relative to 2.6.17-rc6-mm2. A policy patch is also included for reference.
A patch to ipsec-tools/racoon will follow later on the ipsectools-devel list.
ipsec-tools 0.6.5 src in FC rawhide already has the setkey changes needed to work with this.

FUNCTIONAL DESCRIPTION:

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.

 include/linux/security.h                     |  116 ++++++++-
 include/net/flow.h                           |    5 
 include/net/sock.h                           |    9 
 net/core/flow.c                              |    7 
 net/core/sock.c                              |    2 
 net/key/af_key.c                             |   22 +
 net/xfrm/xfrm_policy.c                       |   28 +-
 net/xfrm/xfrm_state.c                        |   12 -
 security/dummy.c                             |   28 ++
 security/selinux/hooks.c                     |   33 ++
 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              |   22 +
 security/selinux/ss/mls.c                    |   20 -
 security/selinux/ss/mls.h                    |   20 +
 security/selinux/ss/services.c               |   48 ++++
 security/selinux/xfrm.c                      |  200 ++++++++++++++---
 19 files changed, 471 insertions(+), 106 deletions(-)


This patch:

 security/selinux/include/av_perm_to_string.h |    1 +
 security/selinux/include/av_permissions.h    |    1 +
 2 files changed, 2 insertions(+)


--- linux-2.6.16.vanilla/security/selinux/include/av_permissions.h	2006-06-12 17:49:44.000000000 -0500
+++ linux-2.6.16/security/selinux/include/av_permissions.h	2006-06-19 19:48:24.000000000 -0500
@@ -909,6 +909,7 @@
 #define ASSOCIATION__SENDTO                       0x00000001UL
 #define ASSOCIATION__RECVFROM                     0x00000002UL
 #define ASSOCIATION__SETCONTEXT                   0x00000004UL
+#define ASSOCIATION__POLMATCH                     0x00000008UL
 
 #define NETLINK_KOBJECT_UEVENT_SOCKET__IOCTL      0x00000001UL
 #define NETLINK_KOBJECT_UEVENT_SOCKET__READ       0x00000002UL
--- linux-2.6.16.vanilla/security/selinux/include/av_perm_to_string.h	2006-06-12 17:49:44.000000000 -0500
+++ linux-2.6.16/security/selinux/include/av_perm_to_string.h	2006-06-19 19:48:24.000000000 -0500
@@ -239,6 +239,7 @@
    S_(SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, "sendto")
    S_(SECCLASS_ASSOCIATION, ASSOCIATION__RECVFROM, "recvfrom")
    S_(SECCLASS_ASSOCIATION, ASSOCIATION__SETCONTEXT, "setcontext")
+   S_(SECCLASS_ASSOCIATION, ASSOCIATION__POLMATCH, "polmatch")
    S_(SECCLASS_PACKET, PACKET__SEND, "send")
    S_(SECCLASS_PACKET, PACKET__RECV, "recv")
    S_(SECCLASS_PACKET, PACKET__RELABELTO, "relabelto")

Re: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[James Morris]

On Tue, 20 Jun 2006, Venkat Yekkirala wrote:

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

Can you clarify whether, with this patch, Linux will then have a complete 
labeled network implementation in terms of both LSPP compliance and common 
user requirements?

> 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 needs to be resolved, along with labeling for all kernel owned 
socket/tw objects.  I'm not entirely clear on why this doesn't already 
work, as it is using IPsec, which should certainly be able to encapsulate 
all of this traffic.

It would also be interesting to know what kind of testing this code as 
had.


- James
-- 
James Morris
<jmorris@namei.org>

RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[Venkat Yekkirala]

> Can you clarify whether, with this patch, Linux will then 
> have a complete 
> labeled network implementation in terms of both LSPP 
> compliance and common 
> user requirements?

I can't comment on the LSPP compliance issue since the specific/proprietary
security target being used might really decide what's needed.

As for common user requirements, at least as I understand them, I would
look for the following in addition to this patch:

- Auto-labelling of child sockets for TCP (I am planning on sending a
separate
  patch out in the next few days).
- Using the label from the incoming packet while sending timewait
acknowledgements
  and other packets sent on behalf of kernel sockets.
- sid prioritization among the current mix of secmark, ipsec, and the
upcoming netlabel
- Replacing secmark on output with an access check in postrouting.
- localhost traffic handling with regard to labelling.

> 
> > 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 needs to be resolved, along with labeling for all kernel owned 
> socket/tw objects.

Resolved these should be, but given the fact that this patch doesn't
introduce this problem in the first place, and given the value it adds to
the
xfrm stuff, my hope would be for this patch to be treated separately. I am
hoping
for 2.6.18 if possible.

>  I'm not entirely clear on why this 
> doesn't already 
> work, as it is using IPsec, which should certainly be able to 
> encapsulate 
> all of this traffic.

Sans label-based checks, no problem. But with label-enhanced checks in
place,
we need to have the label to use, which we don't since there's no real
socket present which normally provided the label. One way to handle
this would be to use the label on the incoming packet for the response
as mentioned earlier.

> 
> It would also be interesting to know what kind of testing 
> this code as 
> had.

Primarily functional testing. Joy Latten at IBM is planning
on further testing this using the framework built for the original
work I believe.

RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[James Morris]

On Wed, 21 Jun 2006, Venkat Yekkirala wrote:

> > Can you clarify whether, with this patch, Linux will then have a 
> > complete labeled network implementation in terms of both LSPP 
> > compliance and common user requirements?
> 
> I can't comment on the LSPP compliance issue since the specific/proprietary
> security target being used might really decide what's needed.
> 
> As for common user requirements, at least as I understand them, I would
> look for the following in addition to this patch:
> 
> - Auto-labelling of child sockets for TCP (I am planning on sending a
> separate
>   patch out in the next few days).
> - Using the label from the incoming packet while sending timewait
> acknowledgements
>   and other packets sent on behalf of kernel sockets.

I think we'd want to have these as part of this MLS enhancement patchset.  

As-is, it's not functional in a production quality sense, in that, simple 
common actions such as a user pressing ctrl-c in an ftp client can cause 
TCP to break, because packets not owned any more by a process will be 
labeled differently.

Features added to the upstream kernel need to be 'complete' in that they 
provide some minimally functional set of features, and meet a clear user 
requirement.  This code seems to be only partially complete, and it's not 
clear to me (and likely other network maintainers) what a complete 
implementation should look like.

What we need is a design rationale, some kind of detailed discussion of 
what the user requirements are and what the plan is for implementing 
features to meet these requirements.

Then, we can trace patchsets back to the requirements and understand where 
each patchset gets us in terms of orderly progression toward 
specific goals.

> - sid prioritization among the current mix of secmark, ipsec, and the
> upcoming netlabel
> - Replacing secmark on output with an access check in postrouting.

This area in general, the interaction between local packet labeling and on 
the wire labeling, needs some solid analysis and discussion on netdev, so 
that the correct solution can be implemented.

It should not be an afterthought.

> - localhost traffic handling with regard to labelling.

Again, this is an important area, but currently seems like an 
afterthought.

And what about userland APIs relating to MLS labeling?  Does the kernel 
currently provide everything you think you need in this respect?

What about polyinstantiated ports?

What about interaction with namespaces and containers?


> > > 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 needs to be resolved, along with labeling for all kernel owned 
> > socket/tw objects.
> 
> Resolved these should be, but given the fact that this patch doesn't 
> introduce this problem in the first place, and given the value it adds 
> to the xfrm stuff, my hope would be for this patch to be treated 
> separately. I am hoping for 2.6.18 if possible.

The problem is that not all of the packets are being labeled the way you 
want them to be.  It's a partial solution which I can't imagine being 
useful to anyone in a practical scenario.

Upstream developers are not experts in MLS, yet need to be able to make 
informed decisions on whether patches being submitted are appropriate: 
better documentation is required.

The original SELinux submissions presented a significant shift in thinking 
on security, but they were supported by extensive documentation including 
the user requirement for MAC and detailed design rationale.  This made it 
possible for kernel maintainers to understand what was being submitted.

Similar is required for these MLS enhancements to networking, including 
some broader thinking about general architectural directions (e.g. how 
this fits in with namespaces, as mentioned above, and also possibly, 
whether APIs and other components are suitable also for legacy MLS 
labeling schemes, at least two of which are being worked on).

There's also the question of ongoing maintenance in the mainline kernel.  
Unfortunately, there's been an increasing trend recently for companies to 
drop code over the wall.  For example, once they get it to some basic 
level of completeness, and the initial patches are merged, their 
developers are reassigned to other projects and the upstream maintainers 
are left with code that's not yet up to Linux kernel quality and also 
something they may not understand very well.  So, we need to know whether 
TCS or anyone else with expert knowledge of MLS will be helping months or 
years down the track, once this code has been merged.


- James
-- 
James Morris
<jmorris@namei.org>

RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments

[Chad Hanson]

 
> There's also the question of ongoing maintenance in the
> mainline kernel.  Unfortunately, there's been an increasing
> trend recently for companies to drop code over the wall.  For 
> example, once they get it to some basic level of completeness,
> and the initial patches are merged, their developers are 
> reassigned to other projects and the upstream maintainers 
> are left with code that's not yet up to Linux kernel quality
> and also something they may not understand very well.  So, we
> need to know whether TCS or anyone else with expert knowledge
> of MLS will be helping months or years down the track, once this
> code has been merged.

We are prepared to help with ongoing support for maintenance and 
improvement of the code accepted into the kernel. We like having
the benefit of providing guidance for the OS security development,
which is needed for our solutions, even though there is some added
cost. This is one the reasons we are porting our solutions to Linux.
The bottom line is the security functionality is a necessary 
component for our applications, and we don't want to be dependent
on others to make sure the functionality is being maintained
correctly. 

-Chad