On Thu, Jul 21, 2016 at 9:58 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Kees Cook <keescook@xxxxxxxxxxxx> writes: > >> On Tue, Jul 19, 2016 at 6:13 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>> >>> This patchset addresses two use cases: >>> - Implement a sane upper bound on the number of namespaces. >>> - Provide a way for sandboxes to limit the attack surface from >>> namespaces. >>> >>> The maximum sane case I can imagine is if every process is a fat >>> process, so I set the maximum number of namespaces to the maximum >>> number of threads. >>> >>> I make these limits recursive and per user namespace so that a >>> usernamespace root can reduce the limits further. If a user namespace >>> root raises the limit the limit in the parent namespace will be honored. >>> >>> I have cut this implementation to the bare minimum needed to achieve >>> these objections. >>> >>> Assuming nothing problematic shows up in the review I will add these to >>> my user namespace tree. >> >> This looks great; thank you! I think the design is effective. One >> thought that pops to mind is how does an admin query the current >> number of active namespaces of a given type? (It's likely this is >> already exposed somewhere and I just don't know where to look...) > > You want to give me your acked by on the patches? Sure thing, consider the series: Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> -Kees -- Kees Cook Chrome OS & Brillo Security _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
