[redhat-lspp] Re: LSPP Development Telecon 06/19/2006 Minutes

[Ted]

On Wed, 2006-06-21 at 21:19 -0600, Eric W. Biederman wrote:
> Dave Hansen <haveblue at us.ibm.com> writes:
> 
> > Quoting Ted (txtoth at gmail.com):
> >> Can anyone point me to a good source of information on namespaces in
> >> general and network namespaces specifically. Are network namespaces
> >> something that could be utilized through xinetd to get polyinstantiated
> >> port functionality?
> >
> > I was just talking to Serge about this on IRC a bit.  I think network
> > namespaces might do some of what you want.
> >
> > Note that this is coming from somebody (me) that has never written a
> > line of networking code in his life.  So, don't pay too much attention.
> > Just brainstorming.
> >
> > One of the important things that they give you is the ability to have
> > multiple stupid daemons listening on "*:80".  Each daemon thinks they
> > "own" that port.  However, the network namespace patches make sure that
> > such a daemon doesn't receive any packets not meant for an IP owned by
> > that daemon.
> >
> > So, if you added network namespaces with a rewriting netfilter rule that
> > would mangle destination addresses to match the IP address of a
> > containerized daemon, I _think_ you might be able to get what you want.
> >
> > So,
> >
> > 1. packet comes in for port 80
> > 2. packet is tagged by secmark
> > 3. packet matches netfilter rule, is redirected to a _specific_ IP
> > 4. packet reaches containerized daemon listening on port 80
> 
> Ack.  That would probably work.
> 
> I'm not certain what is meant by a polyinstantiated port,
> and until then I can't see if it helps.
> 

Lets say on an MLS systems I want to run a web server at each level
(Unclassified, Confidential, Secret, etc...) with each instance binding
to port 8443 which I'd call a polyinstantiated port.

> Network connections are a quad of
> <source address, source port, destination address, destination port>
> which cover all of the interesting cases I can think of for connecting
> things together.  I don't know what else you can filter on.
> 
> The way to think about network namespaces from a user perspective are
> simply multiple instances of the networking stack.  If you can do something
> today with linux and multiple machines you will eventually be able to do
> it on one machine with network namespaces.
> 
> Assuming we can reach an implementation without measurable overhead.
> 
> Eric