David Lamparter <equinox@xxxxxxxxxx> writes: >> ... Eric W. Biederman wrote: >> Now it probably needs to be better documented that /proc/*/net/* >> have the same inode number if the network namespace is the >> same, as everyone including myself overlooked this very handy >> existing property. > > Eh, so did I. But, yes, very nice. > > On Sat, May 21, 2011 at 05:15:38PM -0700, Eric W. Biederman wrote: >> Additionally that solution will work for comparing network namespaces >> that don't happen to have any processes in them at the moment. Because >> fstat works on file descriptors. > > Hm. I have a peeve here. Assume I am a... rogue admin, whatever. I have > root on a router. I create a new network namespace, put a macvlan of > eth0 in it and a macvlan of eth1. I enable ip_forward. > > Then I make a mount namespace, bind-mount the net namespace, bind mount > the mount namespace and terminate all processes that reference it (yes > this does work, i just checked [!]). You must be using an older version of my patchset than what I have queued for Linus. Bind mounting the mount namepsace and creating reference counting loops is a weird and ugly case. So for the moment I am not supporting the mount namespace, until I can think through the consequences. > Now I can use it to bypass all firewall rules, IDS, whatever. > > How is any normal admin, monitoring script or whatever else able to > detect this? Which is why we I proceed slowly and cautiously with adding new kernel interfaces. It is hard to think of everything until you can actually put it into use, and play with it. Other than not allowing bind mounting the mount namespace I don't have any all encompassing really good answers at the moment. I do have a few small answers. For network namespaces you can look in /proc/slabinfo and see how many you have, unless slub is lying to you. On the switch your server is connected to you can look at the mac table and see which mac addresses are currently in use, and notice if there are unaccounted for mac addresses. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
