[Openswan dev] [RFC 1/1] Labeled IPsec communication

[Venkat Yekkirala]

> -----Original Message-----
> From: Paul Wouters [mailto:paul at xelerance.com]
> Sent: Tuesday, October 30, 2007 5:43 PM
> To: Venkat Yekkirala
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] [RFC 1/1] Labeled IPsec communication
> 
> 
> On Tue, 30 Oct 2007, Venkat Yekkirala wrote:
> 
> > This patch adds the ability for pluto to negotiate labeled security
> > associations (racoon already supports this) for use by SELinux and
> > such LSMs.
> 
> Thanks for the patch!
> 
> > context for inter-operation with racoon, but I would appreciate your
> > review and comments.
> 
> Please look at proving patches for openswan 2.5.x (git 
> #testing), as the
> 2.4.x is in maintenance release, and no new features are being added.

Will do.

> 
> Also, like other functionality that not everyone may want, it needs to
> be a build option via Makefile.inc, so that it is easy to 
> build with and
> without selinux support.

Sure.

> 
> I can pick this up in a few weeks to convert it to 2.5 and to use a
> USE_SELINUX= flag, but feel free to send in a newer patch.
> 
> Also, we are not very familiar with SElinux. It would be very good to
> add various testcases in testing/pluto/ so that we can keep the code
> in a working shape.


Broadly speaking, on SELinux, subjects (typically processes) and
objects (files, etc.) are labeled with security contexts and access
control is performed when a subject accesses an object based on SELinux
policy loaded into the kernel at bootup time. You can find more info at
http://www.nsa.gov/selinux/

Traditionally, for conveying the label of a packet, IP Options were used
but it has its limitations. To get around these, a labeled IPsec SA mechanism
was upstreamed into the kernel last year.

The following is typically the flow:

1. A user indicates the use of "labeled" SAs for a specific connection
   by specifying a context as part of the connection definition in ipsec.conf
   Say the context specifies the range secret to top_secret. Now all communication
   involving secret and top secret processes for that connection MUST use
   IPsec and further a UNIQUE SA for each label in the range (meaning one
   SA with the label Secret and another for Top Secret). The remote end
   would then decipher the label of a packet based on the SA that has been
   used by the packet.

2. The specific label calling for an SA is passed upto pluto by the kernel
   as part of the acquire message. Pluto then includes this label in the
   negotiation so that both ends tie this label to the SAs established as
   part of the negotiation and further load the SAs into the kernel with
   the label tied to them. The kernel would then use the appropriate SA
   based on the label of the process and the label of the SA; IOW, it would
   use an SA labeled with Secret for Secret processes/packets and an SA labeled
   Top Secret for Top Secret processes/packets.

That's pretty much all there's to it. Now the biggest impact is where
several SAs (each for a different label) are tied to the same connection.
This is where I would specifically appreciate your review and comments
since I may have easily missed assumptions to the contrary elsewhere
in the code.

Also, when a remote peer initiates quick mode, the local pluto would
need to make sure the label that arrives "polmatch"es (see security.c)
to a policy before deciding that connection applies. I would appreciate
a review here as well.

BTW, the patch also includes more recent kernel headers for now.

Thanks,

venkat

> 
> Paul
>