From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753530AbcGVS6N (ORCPT ); Fri, 22 Jul 2016 14:58:13 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:35728 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbcGVS6K (ORCPT ); Fri, 22 Jul 2016 14:58:10 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Colin Walters Cc: Linux Containers , Andy Lutomirski , Jann Horn , Kees Cook , Nikolay Borisov , "Serge E. Hallyn" , Seth Forshee , linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> <1469194399.3817016.673814953.7581706C@webmail.messagingengine.com> Date: Fri, 22 Jul 2016 13:45:07 -0500 In-Reply-To: <1469194399.3817016.673814953.7581706C@webmail.messagingengine.com> (Colin Walters's message of "Fri, 22 Jul 2016 09:33:19 -0400") Message-ID: <87poq5y0jw.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=1bQfe7-0006mu-Rk;;;mid=<87poq5y0jw.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+CBeeJQQPurn+AYeP/O8DRNjoo4CvP4e4= 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.4999] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Colin Walters X-Spam-Relay-Country: X-Spam-Timing: total 672 ms - load_scoreonly_sql: 0.10 (0.0%), signal_user_changed: 3.9 (0.6%), b_tie_ro: 2.8 (0.4%), parse: 1.04 (0.2%), extract_message_metadata: 26 (3.9%), get_uri_detail_list: 3.3 (0.5%), tests_pri_-1000: 6 (0.9%), tests_pri_-950: 1.98 (0.3%), tests_pri_-900: 1.78 (0.3%), tests_pri_-400: 37 (5.5%), check_bayes: 35 (5.2%), b_tokenize: 13 (2.0%), b_tok_get_all: 11 (1.6%), b_comp_prob: 4.7 (0.7%), b_tok_touch_all: 3.4 (0.5%), b_finish: 0.88 (0.1%), tests_pri_0: 412 (61.2%), check_dkim_signature: 0.90 (0.1%), check_dkim_adsp: 4.2 (0.6%), tests_pri_500: 178 (26.4%), poll_dns_idle: 150 (22.2%), 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 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. > The high level makes sense to me...most interesting is > per-userns sysctls. I'll note most current container managers > mount /proc/sys read-only, and Docker specifically drops > CAP_SYS_RESOURCE by default, so they'd likely need to learn > how to undo that if one wanted to support recursive container usage. > We'd probably need to evaluate the safety of having /proc/sys > writable generally. (Also it's rather common to filter out CLONE_NEWUSER > via seccomp, but that's easy to undo) Just using a user namespace replaces most of those precautions. > But that's the flip side - if we're aiming primarily for an upstreamable > way to *limit* namespace usage, it seems sane to me. Yes. The primary target is to stop applications that have gone buggy and allocated a crazy number of namespaces. The secondary target is to allow sandboxes to disable creation of additional namespaces. Just set the limit to 0 and drop caps, or similarly set the limit to 1 and create another fresh set of nested namespaces. Eric