Richard Guy Briggs <rgb@xxxxxxxxxx> writes: > A namespace cannot directly migrate from one container to another but > could be assigned to a newly spawned container. A namespace can be > moved from one container to another indirectly by having that namespace > used in a second process in another container and then ending all the > processes in the first container. Ugh no. The semantics here are way too mushy. We need a clean crisp unambiguous definition or it will be impossible to get this correct and impossible to use for any security purpose. I understand the challenge. Some of the container managers share namespaces between containers. Leading to things that are not really contained. Please make this concept like an indellibale die. Once you are stained with it you can not escape. If you don't meet all of the criteria you aren't stained. The justification that I heard, and that seems legitimate is that it is not timely and it is hard to make the connection between the distinct unshare, setns, and clone events and what is happening in the kernel. With that justification definitely the network namespace needs to be stained if it is appropriate. I also don't see why this can't be a special dedicated audit message. I just looked at the code in the kernel and nlmsg_type is a u16. There are only a handful of audit message types defined. There is absolutely no reason to bring proc into this. I have the same reservation as the others about defining a new cap for this. It should be enough to make setting the container id a one time thing for a set of processes and namespaces. If this is going to be security it needs to be very simple and very well defined. Eric -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
