[redhat-lspp] Xinetd patches for selinux context configuration

[Paul Moore]

On Wednesday 29 November 2006 6:30 pm, James Antill wrote:
> On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote:
> > James Antill wrote:
> > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote:
> > >>I'm not sure the approach is quite workable yet either - if you
> > >>configure xinetd to use labeled networking but the incoming connection
> > >>is coming from a host that doesn't support it, getpeercon() will fail
> > >>and you need to gracefully deal with it (e.g. fall back to some
> > >> default, possibly based on the client machine's address).
> > >
> > >  Isn't this exactly what netlabel is for? Do we really want to
> > > duplicate that for each daemon?
> >
> > NetLabel is a method of explicit labeled networking, i.e. it sends
> > security attributes with each packet that both hosts must understand.
>
>  As I understand it, you can say label received packets from host X with
> context Y. Is that not so?

Sorry for any confusion, I thought you were implying that NetLabel assigns a 
context to a packet simply based on the IP address of the remote host.  A 
better explanation of NetLabel/CIPSO is below ...

For NetLabel if the incoming packet is labeled by the remote host, i.e. a 
CIPSO IP option is present in the packet's headers, then NetLabel will create 
a context for the packet based on the concatenation of the 
SECINITSID_UNLABELED TE values and the CIPSO option's MLS label.  In practice 
this allows you to say that domain X is allowed to receive packets from 
remote domains/processes which are running with the same MLS label; if domain 
X has the right MLS type attributes associated with it then it can receive 
packets from remote domains/processes that do not match it's own MLS label 
(see the MLS constraints file to see what I mean).  The IP address of the 
remote host never comes into play.

-- 
paul moore
linux security @ hp