Re: [PATCH v2 00/10] userns: sysctl limits for namespaces
From: Eric W. Biederman
Date: Fri Jul 22 2016 - 22:24:18 EST
Kees Cook <keescook@xxxxxxxxxxxx> writes:
> On Fri, Jul 22, 2016 at 11:45 AM, Eric W. Biederman
> <ebiederm@xxxxxxxxxxxx> wrote:
>> Colin Walters <walters@xxxxxxxxxx> writes:
>>> On Thu, Jul 21, 2016, at 12:39 PM, Eric W. Biederman 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
>>> Perhaps this is obvious, but since you didn't quite explicitly state it;
>>> do you see this as obsoleting the existing downstream patches
>>> mentioned in:
>>> It seems conceptually similar to Kees' original approach, right?
>> Similar yes, and I expect it fills the need. My primary difference is
>> that I believe this approach makes sense from a perspective of assuming
>> that user namespaces or other namespaces are not any buggier than any
>> other piece of kernel code and that people will use them.
>> I don't see these limits making sense from a perspective that user
>> namespaces are flawed and distro kernels should not have enabled them in
>> the first place. That was my perception right or wrong of Kees patches
>> and the related patches that landed in Ubuntu and Debian.
>> With Kees approach I could not see how to handle the case where some
>> applications on the system wanted user namespaces and others don't.
>> Which made it very nasty for future evolution and more deployment of
>> user namespaces. Being per user namespace these limits can be used to
>> sandbox applications without affecting the rest of the system.
> While it certainly works for my use-case (init ns
> max_usernamespaces=0), I don't see how this helps the case of "let
> user foobar open 1 userns, but everyone else is 0", which is likely
> the middle ground between "just turn it off" and "everyone gets to
> create usernamespaces". I'm personally not interested in that level of
> granularity, but in earlier discussions it sounded like this was
> something you wanted?
So the case I really care about is when there is limited use, so people
don't have to redesign their applications. In this case if you want to
disable things in a sandbox like way you just create a user namespace
and set the count to 0 in that user namespace.
A whole system disable I tend to think is a stupid configuration for a
new system. It gets into people negotiating for what they need, and I
don't see that as sustainable. I prefer good usable defaults.
I would have loved to have done something with per user limits so it
could be disabled for a selection of users, but it turns out the kernel
doesn't have appropriate data structures for to hold limits for users
that have not logged in.
And in practice I don't care the case where 1 user is allowed but not
the others, I care about disallow this user/program that is in a
sandbox. I also seem to recall people have problems with using seccomp
to disable things. All of that said a per user policy is easily
implemented in pam by setting the size count for a specific user to 0.
I do think a limit to catch applications that go crazy is very sane, and
that is primarily what is implemented here.