[redhat-lspp] Xinetd patch

[Stephen Smalley]

On Thu, 2005-09-29 at 09:55 -0400, Steve Grubb wrote:
> On Thursday 29 September 2005 09:41, Joe Nall wrote:
> > If you have a system with hundreds of compartments and their  
> > permutations (for example an inverse bit for each country), the
> > configuration overhead of this approach is prohibitive.
> 
> I think we could allow a range of compartments so that each one is not 
> required. We could also allow an option that means match any context. But 
> generally for anything like this in xinetd, we've tried to give the admin the 
> hooks to restrict connections if they choose to. 
> 
> If you allow xinetd to start services at any level/compartment, xinetd is 
> basically unconfined.

Yes, I agree with this - the admin needs to be able to bound the amount
of trust based on the client, so specifying at least an authorized range
that the client's level must fall within is reasonable.

With regard to the implementation, it looks like you just use the peer
socket's context as is for the process in the stream case, which is
definitely not what we want (because at least the TE domain should
reflect the actual service, not the client's domain), whereas in the
datagram case, you are only inheriting the level/range from the datagram
and retaining the rest of the context, which seems preferable.

Also, you are currently doing a dynamic context transition rather than
an exec-based one.  At least for the exec-based services, I'd suggest
that you perform a security_compute_create to get the transition context
for the service based on its program context, mutate the range/level,
and then use setexeccon prior to the exec for the transition.  Not sure
about any in-process services provided by xinetd itself.

-- 
Stephen Smalley
National Security Agency