[redhat-lspp] Xinetd patches for selinux context configuration

[Stephen Smalley]

On Wed, 2006-11-29 at 18:30 -0500, 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?

I think you are confusing netlabel with secmark, and also still thinking
about secid reconciliation (which didn't get accepted).  If secid
reconciliation had been accepted, then yes, you could assign a default
label based on client host or other properties of the packet via secmark
and have it returned by getpeercon if there was no explicit label on the
packet.  But the final resolution of that lengthy debate was that
secmark would remain separate from labeled networking, and that
getpeercon would only return a context if labeled networking was in use
on the connection (likewise for SCM_SECURITY on datagrams).

I agree though that replicating the lookup of a default context by host
per daemon wouldn't be desirable, so one might want a general service
provided by libselinux.  A topic for selinux list, not here, yet again.

-- 
Stephen Smalley
National Security Agency