Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

[Venkat Yekkirala]

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

The following is not extensive in a formal/theoretical sense, but hopefully
addresses the need here.

Needless to say, it is hoped MLS experts and others out there would join this
discussion.

USER REQUIREMENTS:

The broad user requirements for labeled networking would be that of information
labeling and flow control. Specifically,

1. Data labeling:
	a. data must be labeled where it originates.
	b. data must retain that label (or its interpretation in a given domain)
	   when conveyed in a trustworthy manner.

2. Flow control:
	a. data must be flow controlled at the point it is consumed.
	b. data must be flow controlled at the point it simply flows thru.

3. Data processing support:
	a. Multi-level processes: provision for a sufficiently privileged/trusted
	   process (e.g. Multi-level server) to read/write data labeled at
	   different levels (specifically any/all levels within a given range).

	   Such trusted/privileged processes would usually operate at a given
	   level but would be able to read/write data at levels other than the
	   level they are operating at, as allowed by policy.

	b. Multiple single-level processes: provision for a process (usually a
	   legacy, unmodified, untrusted) to be multi-instantiated, with each
	   process binding to the same port but running at a different level.

	   One way to support this is by providing for port polyinstantiation.

	c. Multiple multi-level processes: provision for a process to be multi-
	   instantiated, with each process binding to the same port but running
	   at a different range (specifically all the levels in the range).

	   3(b) is a special case of this.

NOTE: We (TCS) have products that currently use 3(a) but not 3(b) or 3(c). As
such our thrust here is geared toward the former along with 1 and 2. There is
currently an ongoing discussion about using network namespaces for port
polyinstantiation at
http://www.redhat.com/archives/redhat-lspp/2006-June/msg00156.html.

PROPOSED DESIGN:

Given the above requirements the following design is proposed:

Socket labeling (SOCK):

1. Label socket to be at the same level as the creating process unless the
   process is privileged and has specified a different label (R3a).

2. Create TCP child sockets with the MLS level taken from the peer
   context, relying on the existing process-to-socket sendmsg, recvmsg
   controls to protect the sockets (R3a).

On the inbound (INBND):

The following applies to traffic destined for local sockets (INPUT) as well as
forwarded traffic (FORWARD).


1.	Set the packet's secmark to the iptables context (R1a).

2.	If it is an ipsec packet,
	Check that data with the ipsec label can "come thru" the "pipe" as
	represented by the current secmark (iptables context) (R2b). That is,
	check to make sure the ipsec MLS label falls WITHIN the MLS range of
	the "pipe", and that the ipsec TE context can "come thru" the TE context
	of the "pipe" per TE policy.
		Yes: Set the secmark to ipsec label (replacing iptables context
		     set in step 1) (R1b).
		No:  Drop packet.

3.	If it’s a CIPSO packet (NetLabel),
	Check that data with the CIPSO label can "come thru" the "pipe" as
	represented by current secmark (ipsec or iptables context) (R2b).
		Yes: Set the secmark to CIPSO label (R1b).
		No:  Drop packet.

4.	INPUT ONLY: Check socket can receive the packet. That is, check to
	make sure the packet has MLS and TE read access to the packet per
	SELinux policy (R1a, R3a, R3b).

5.	FORWARD ONLY: Jump to OTBND2 below.

On the outbound (OTBND):

The following applies to locally-generated (OUTPUT) as well as forwarded
(FORWARD) traffic.

1.	OUTPUT ONLY:
	a. Set secmark of the packet to the label of the socket unless its a
	   datagram, the process is privileged and is allowed to specify
	   a different label for the datagram per policy (R1a, R3a, R3c).

	b. If there's no real socket to take the label from, and this packet is
	   in response to a received packet, use the level from the received
	   packet, taking the TE portion of the context from the pseudo-socket
	   on whose behalf the packet is being sent.

2.	If using CIPSO, set the option derived from Secmark (R1a). Drop packet
	if a valid CIPSO option can't be derived.

3.	If using IPSec (packet secmark must fall within the range of a xfrm
	policy rule), choose a matching SA (again packet label must fall within
	the range for the security association) (R2b, R1b). Set the secmark to
	ipsec label (replacing the label it was set to in step 1).

4.	In the POSTROUTING chain of the mangle table:
	a. Determine the iptables context per the iptables POSTROUTING
	   policy chain in the mangle table. But it WON’T go into the secmark
	   of the packet like it currently does.
	b. Check that the packet can "pass thru" the "pipe" as represented by
	   the iptables context (R2b). That is, the secmark's MLS label must
	   fall WITHIN the MLS range of the "pipe", and the secmark's TE context
	   can "pass thru" the TE context of the "pipe" per TE policy.

		NOTE: This means that data may not necessarily have the
		ability to go out by itself, just that it can go in an ipsec
		pipe and that pipe can go out.  You can have traffic that is
	        only allowed to leave via ipsec this way. data_t can not go out
 		of iface_t, but it can go into ipsec_pipe_t, which can go out
		of iface_t.
	

User API (UAPI):

1. IPSec xfrms:
	a. Specify labels with xfrm policy, association rules.
	b. Specify label as part of acquire messages to IKE daemons
	   so the label can be made a part of the negotiation process.

2. Socket labeling:
	a. Specify label to be used for sockets to be created.

3. Datagram labeling:
	a. Specify label for a datagram being written.


OUTSTANDING ITEMS (ITEM):

1. Support for granular IPSec associations (INBND2, OTBND3).

2. Use level from incoming packet for outgoing packet when no real socket
   present (OTBND1b).

3. TCP child sockets (SOCK2).

4. Checks against iptables context on outbound (OTBND4).

5. Socket labeling (UAPI2).

6. CIPSO (NetLabel) and other legacy labeling mechanisms.

7. Datagram labeling (UAPI3).

8. Port polyinstantiation (INBND4a).



ARCHITECTURAL DIRECTIONS:

Interaction with containers/network namespaces:

I have only cursorily glanced at containers and network namespaces, but
intuitively speaking, they could be defined to operate at different MLS
ranges and meet the above requirements in terms of handling data
that falls within those ranges.

Example:

Container/namespace A: Unclassified to Confidential
Container/namespace B: Secret to Top Secret

If a packet were to arrive with the label Confidential, it would need to be
"routed" to container A. Similarly, a packet labeled Secret would be routed
to namespace B. This would be satisfy Requirement 3c (R3c for short) .

Also, a packet labeled Secret must NOT be allowed to be sent from Container A,
but must be allowed from B, meeting Requirement 2.b (R2b for short).


GAME PLAN FOR PATCHES:

1. Patch for ITEM1, ITEM2, ITEM3 (being worked by TCS) should be out in a few
   days.

2. Patch for ITEM4.

3. Patch for ITEM5 has already been done by Eric Paris and is being considered
   for upstreaming.

4. Patch for ITEM6: Paul Moore has done a "NetLabel" patch for this and the
   patch is currently under review upstream.

5. Patch for ITEM7: TCS currently have no plans to design and implement this.

6. Patch for ITEM8: There's currently an ongoing discussion about possibly
   using network namespaces for this purpose. TCS have no plans to work on this
   at the current time.

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

[James Morris]

On Mon, 26 Jun 2006, Venkat Yekkirala wrote:

> > 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.
> 
> The following is not extensive in a formal/theoretical sense, but hopefully
> addresses the need here.

This is great, thanks.  Exactly what was needed and much appreciated.

I think the interaction with secmark as you describe sounds good.

> 3. Patch for ITEM5 has already been done by Eric Paris and is being considered
>   for upstreaming.

This is in Linus' tree now.

> 5. Patch for ITEM7: TCS currently have no plans to design and implement this.
> 

(Datagram labeling)

I guess we'd probably use SCM_SECURITY for this (similar to 
IP_CMSG_PASSEC for receiving the label).

Is this enough support for user API support at the kernel level in terms 
of setting and getting labels?


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

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

[Paul Moore]

On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote:
> USER REQUIREMENTS:
>
> The broad user requirements for labeled networking would be that of
> information labeling and flow control. Specifically,
>
> 1. Data labeling:
> 	a. data must be labeled where it originates.
> 	b. data must retain that label (or its interpretation in a given domain)
> 	   when conveyed in a trustworthy manner.

{snip}

> PROPOSED DESIGN:
>
> Given the above requirements the following design is proposed:
>
> On the outbound (OTBND):
>
> The following applies to locally-generated (OUTPUT) as well as forwarded
> (FORWARD) traffic.
>
> 1.	OUTPUT ONLY:
> 	a. Set secmark of the packet to the label of the socket unless its a
> 	   datagram, the process is privileged and is allowed to specify
> 	   a different label for the datagram per policy (R1a, R3a, R3c).
>
> 	b. If there's no real socket to take the label from, and this packet is
> 	   in response to a received packet, use the level from the received
> 	   packet, taking the TE portion of the context from the pseudo-socket
> 	   on whose behalf the packet is being sent.
>

Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take 
the label of the process/domain which sends the data to the socket?  After 
all, the process/domain is the "origin" of the data.  This seems to be 
particularly important in the case of fork()-then-exec() where you could have 
a socket created at a different context from the domain currently writing to 
it.

-- 
paul moore
linux security @ hp

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

[Venkat Yekkirala]

> Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take 
> the label of the process/domain which sends the data to the socket? After 
> all, the process/domain is the "origin" of the data.

Right. This is what "ends up" happening in the non-privileged case. In the
privileged multi-level process case, the label of the data has in fact been
established at the socket creation time itself, and here we are trusting the
privileged multi-level process with sending data out on the right socket with
the knowledge that the data would be labeled with the label of the socket.

>  This seems to be 
> particularly important in the case of fork()-then-exec() where you could have 
> a socket created at a different context from the domain currently writing to 
> it.

It would also help to remember that there are additional process-to-socket
controls (sendmsg, recvmsg) already in place in SELinux.

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

[Venkat Yekkirala]

Venkat Yekkirala wrote:
>> Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) 
>> to take the label of the process/domain which sends the data to the 
>> socket? After all, the process/domain is the "origin" of the data.
> 
> Right. This is what "ends up" happening in the non-privileged case. In the
> privileged multi-level process case, the label of the data has in fact been
> established at the socket creation time itself, and here we are trusting 
> the
> privileged multi-level process with sending data out on the right socket 
> with
> the knowledge that the data would be labeled with the label of the socket.
> 
>>  This seems to be particularly important in the case of 
>> fork()-then-exec() where you could have a socket created at a 
>> different context from the domain currently writing to it.
> 
> It would also help to remember that there are additional process-to-socket
> controls (sendmsg, recvmsg) already in place in SELinux.
> 
In summary it's a matter of architecture.