Eric W. Biederman wrote: > Paul Moore <[EMAIL PROTECTED]> 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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
