From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5862C433DF for ; Mon, 12 Oct 2020 05:01:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C35B2076E for ; Mon, 12 Oct 2020 05:01:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbgJLFBE (ORCPT ); Mon, 12 Oct 2020 01:01:04 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:40362 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726531AbgJLFBD (ORCPT ); Mon, 12 Oct 2020 01:01:03 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kRpx2-006tER-K0; Sun, 11 Oct 2020 23:00:48 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1kRpx1-0005YR-GK; Sun, 11 Oct 2020 23:00:48 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Josh Triplett , "Serge E. Hallyn" , Christian Brauner , Linux Containers , Alexander Mihalicyn , Mrunal Patel , Wat Lim , Aleksa Sarai , Pavel Tikhomirov , Geoffrey Thomas , Joseph Christopher Sible , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Vivek Goyal , Giuseppe Scrivano , Stephane Graber , Kees Cook , Sargun Dhillon , LKML References: <20200830143959.rhosiunyz5yqbr35@wittgenstein> <20201010042606.GA30062@mail.hallyn.com> <20201011205306.GC17441@localhost> Date: Mon, 12 Oct 2020 00:01:09 -0500 In-Reply-To: (Andy Lutomirski's message of "Sun, 11 Oct 2020 17:38:41 -0700") Message-ID: <87h7r0qbqi.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kRpx1-0005YR-GK;;;mid=<87h7r0qbqi.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+R2TJbmPUBT5o1leUsuv79cH+JtdTcZ2U= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski writes: > On Sun, Oct 11, 2020 at 1:53 PM Josh Triplett wrote: >> >> On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote: >> > > 3. Find a way to allow setgroups() in a user namespace while keeping >> > > in mind the case of groups used for negative access control. >> > > This was suggested by Josh Triplett and Geoffrey Thomas. Their idea was to >> > > investigate adding a prctl() to allow setgroups() to be called in a user >> > > namespace at the cost of restricting paths to the most restrictive >> > > permission. So if something is 0707 it needs to be treated as if it's 0000 >> > > even though the caller is not in its owning group which is used for negative >> > > access control (how these new semantics will interact with ACLs will also >> > > need to be looked into). >> > >> > I should probably think this through more, but for this problem, would it >> > not suffice to add a new prevgroups grouplist to the struct cred, maybe >> > struct group_info *locked_groups, and every time an unprivileged task creates >> > a new user namespace, add all its current groups to this list? >> >> So, effectively, you would be allowed to drop permissions, but >> locked_groups would still be checked for restrictions? >> >> That seems like it'd introduce a new level of complexity (a new facet of >> permission) to manage. Not opposed, but it does seem more complex than >> just opting out of using groups for negative permissions. > > Is there any context other than regular UNIX DAC in which groups can > act as negative permissions or is this literally just an issue for > files with a more restrictive group mode than other mode? Just that. The ideas kicked around in the conversation were some variant of having a sysctl that says "This system never uses groups for negative permissions". It was also suggested that if the sysctl was set the the permission checks would be altered such that even if someone tried to set a negative permission, the more liberal permissions of other would be used instead. Given that creating /etc/subgid is effectively opting out of negative permissions already have a sysctl that says that upfront feels like a very clean solution. Eric