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

[Paul Moore]

Eric W. Biederman wrote:
> Paul Moore <paul.moore at hp.com> writes:
>>Dave Hansen wrote:
>>>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.

Assuming the we require each network namespace to have a unique security
label we shouldn't have a problem with one namespace attacking another
as each packet will have a different security label.

> 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.

I really don't like the idea of requiring the use of NAT.

> 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.

If I am understanding you correctly this just sounds like adding IP
aliases to an interface, or just simply adding a new NIC, and assigning
each address to a network namespace.  While it's easy to do and even
easier to secure I don't think it addresses the problem we are trying to
solve - port polyinstantiation - where you can have multiple
applications bound to the same IP/protocol/port with the only difference
being the application's security label.

-- 
paul moore
linux security @ hp