[redhat-lspp] Xinetd patches for selinux context configuration

[Stephen Smalley]

On Thu, 2006-11-30 at 08:06 -0500, Stephen Smalley wrote:
> 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.

BTW, libsepol and libsemanage already have a notion of node (host)
contexts, although those are defined in the policy for certain
permission checks (node_bind, compat send/recv per-packet checks).  Not
sure whether you can leverage the range portion of those contexts for
this purpose.

-- 
Stephen Smalley
National Security Agency