From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754587AbcGVNdZ (ORCPT ); Fri, 22 Jul 2016 09:33:25 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:37696 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754040AbcGVNdV (ORCPT ); Fri, 22 Jul 2016 09:33:21 -0400 Message-Id: <1469194399.3817016.673814953.7581706C@webmail.messagingengine.com> X-Sasl-Enc: b4NgHkSa+Yvz8L/Znh4FIwtDTaT9bia1+Surw/xK3ZFL 1469194399 From: Colin Walters To: "Eric W. Biederman" , Linux Containers Cc: 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 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2ccfea0a In-Reply-To: <87d1m754jc.fsf@x220.int.ebiederm.org> References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> Subject: Re: [PATCH v2 00/10] userns: sysctl limits for namespaces Date: Fri, 22 Jul 2016 09:33:19 -0400 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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) But that's the flip side - if we're aiming primarily for an upstreamable way to *limit* namespace usage, it seems sane to me.