[redhat-lspp] Xinetd patch

[Steve Grubb]

Changing the name of this thread since more than one subject is being 
discussed on it...

On Wednesday 28 September 2005 17:57, Chad Hanson wrote:
> The desired behavior is to spawn off a process at the level of the incoming
> packet. 

I think the "real" desired behavior is to define a context or list of contexts 
that must be met by the incoming connection. This is more like the xinetd way 
to do things. Besides setting up the environment for the service mentioned 
yesterday, xinetd has many features that discriminate about the properties of 
a potential session. It does the "heavy lifting" so that the applications it 
starts can be simpler. All they have to do is read/write stdin/stdout.

> This is true since MLS policy is adverse to changing labels. An 
> example of a few insecure protocols, such as telnet or ftp, would have them
> start daemons at the incoming label. It would break the policy of the
> connected network to have these daemons spawn at higher or lower level as
> the would cause an upgrade/downgrade of data from the client to the server.

Should it? My understanding is that no upgrade/downgrade is allowed to occur. 
If you aren't at the right level, you cannot connect and cannot access data. 
We want xinetd to reject connections that are not valid.

> I have attached an xinetd patch which shows the concepts, but isn't
> entirely applicable to the current code base.

This patch has some work needed for upstream acceptance. On non-mls systems we 
probably do not want it setting contexts. This code will not compile on 
anything other than linux - and even then not all linux distributions. As the 
upstream maintainer of xinetd, I have to consider that. 

I would think that we need to state the valid list of contexts that xinetd 
should accept connections for. 

This patch is also not in the correct place. It needs to be in 
child_process(). Xinetd tries to have minimal code between accept and fork. 
Anything that potentially takes time is done in the child process so that the 
parent can get back to listening. 

I would also think that you want any transition to occur after log_remote_user 
and before starting the service. Which brings up the question about 
logging...xinetd can log several things about a session. Do we want it adding 
the context information to the logs it creates? What about logging the remote 
user, should their ID include level and compartment? Should ident be updated 
to do that, too? If so is that a new RFC?

-Steve