From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752080AbcGWCYQ (ORCPT ); Fri, 22 Jul 2016 22:24:16 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:39603 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbcGWCYL (ORCPT ); Fri, 22 Jul 2016 22:24:11 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Kees Cook Cc: Colin Walters , Linux Containers , Andy Lutomirski , Jann Horn , Nikolay Borisov , "Serge E. Hallyn" , Seth Forshee , "linux-fsdevel\@vger.kernel.org" , Network Development , LKML , Linux API References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> <1469194399.3817016.673814953.7581706C@webmail.messagingengine.com> <87poq5y0jw.fsf@x220.int.ebiederm.org> Date: Fri, 22 Jul 2016 21:11:05 -0500 In-Reply-To: (Kees Cook's message of "Fri, 22 Jul 2016 14:46:52 -0700") Message-ID: <87h9bhqf2e.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bQmbi-0005m9-Pn;;;mid=<87h9bhqf2e.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19ZrBpTVndJ0dWOgeWHhRSOZGqMqjrvjbA= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Kees Cook X-Spam-Relay-Country: X-Spam-Timing: total 1491 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.5 (0.2%), b_tie_ro: 2.4 (0.2%), parse: 1.20 (0.1%), extract_message_metadata: 27 (1.8%), get_uri_detail_list: 4.1 (0.3%), tests_pri_-1000: 10 (0.6%), tests_pri_-950: 1.20 (0.1%), tests_pri_-900: 1.02 (0.1%), tests_pri_-400: 32 (2.1%), check_bayes: 31 (2.0%), b_tokenize: 10 (0.6%), b_tok_get_all: 10 (0.7%), b_comp_prob: 4.6 (0.3%), b_tok_touch_all: 3.0 (0.2%), b_finish: 0.76 (0.1%), tests_pri_0: 1408 (94.5%), check_dkim_signature: 0.83 (0.1%), check_dkim_adsp: 3.7 (0.2%), tests_pri_500: 4.1 (0.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 00/10] userns: sysctl limits for namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees Cook writes: > On Fri, Jul 22, 2016 at 11:45 AM, Eric W. Biederman > wrote: >> Colin Walters 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 >>>> namespaces. >>> >>> 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: >>> https://lwn.net/Articles/673597/ >>> 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. Eric