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

[Eric W. Biederman]

Paul Moore <paul.moore at hp.com> writes:

> Dave Hansen wrote:
>> 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
>> 
>
> My only concern with something like this is that it would probably wreak
> havoc with things that do checksums/HMACs/etc with the IP addresses.  I
> think we should try to avoid packet managling as much as possibile; it
> tends to introduce more problems than it solves (NAT anyone?).  However,
> it may be that someone has already thought of that and found a way
> around it?

Ok.  The way it looks to me is this:

In the first network namespace connected to the outside world.
We setup firewall rules to look at the security association (ipsec/ipauth)
with the packet and depending forward that packet out different interfaces
depending upon our security rules.

Each of the different outgoing interfaces hooks to a different network
namespace.  With probably a different security level.

The ip address is configured the same on the filter network namespace,
and the destination network namespaces.

The tricky bit is that the filter network namespace needs firewall rules
in place so that the returning packets are not allowed to spoof each other.

I think you can set that up with multiple machines today, or at least
some variety of that.  Sharing the ip address between different security
levels sounds scary to me though.  NAT inside the box between multiple network
namespaces may be more security.

The only truly sane way I can think to do this is to give each network namespace
it's own ip address.  Which is a lot less complicated therefore easier to secure.
Then on your filter namespace all you have to do is put in rules that suppress
attempts to spoof another network namespaces IP address.  But that kind of thing
is routine for routers.

Eric