Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2765627imn; Tue, 2 Aug 2022 15:12:02 -0700 (PDT) X-Google-Smtp-Source: AA6agR4E5xP3ZT2ro+LDvR/XB1X0SCh+DyrxrkIDZdqcy5HSFD0LoNoR0gePRiv+853J6iME4oIL X-Received: by 2002:a05:6402:3595:b0:43d:710a:3f3f with SMTP id y21-20020a056402359500b0043d710a3f3fmr15251452edc.375.1659478321890; Tue, 02 Aug 2022 15:12:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659478321; cv=none; d=google.com; s=arc-20160816; b=GifMQmuCv02cGYTOMkT6B8JhC2iCY1uowgToeCZR5f0AnfF26MSC3iAomo9HJ4hQ31 dShWAHocumJoC1mejMc6PXk0uFbw8drMD9uSAu4iw2gvOUH1WUqTBatkqzl3BheWwPVr C0i6FF5gSyJn4+uZ/ib3wcwBIl4ir366XxAjBbBoEFoaCC0hUcPO+HKL3+ft1wQElF0r cgXh4RrGpPq5g5w2J2aGbiOPW0rGJT0fiv3Fbd1oR+QnJ3rkTYD9G5gQnuPvE6qoP7c5 QbUlQb4nHtoQmNpRTI/Q1Yh6wrSmOXxvabjjy3Bcj1XciMI1UBFUeuOzW2yXbhhUYTMX xrWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=M50/UBdnSOvDwy1Wclsf9zALfAPArns3IG4NYcEA3Vc=; b=quWLCbmNSvxv156FQNLscLLYR1zTYam9gNar5H07LFw4dtZ6E5+NArBH4I8Ma58dOg C3W6RkhzPD73DUE4S7hI3Tlw1W3TGH/xX+B2sekwHjZYSLeSWwqzjuuzJ1INJ6sDvj87 K4J6+Rusp5paaCA1SFT3U/8mtn1c0DWtoI/jb3Cru6B/Q+krOOI8LKTOc97eR0OGr970 ncIk0XiRM0v1QgBi80ElMIg5kCs6kqxSyjwpk9AptibHwzxKoHH0sSNZMd2Kw1F/jkET ZGdHksrnCMjXLnu1wRnZ9mMIRZ2PBdeekqM5pB1C9NPmRCuzreuxS3UlEpFTmPqPt9Lc Kh5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y25-20020a170906471900b0072b29827476si11595900ejq.287.2022.08.02.15.11.37; Tue, 02 Aug 2022 15:12:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236953AbiHBVfN (ORCPT + 99 others); Tue, 2 Aug 2022 17:35:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235162AbiHBVfJ (ORCPT ); Tue, 2 Aug 2022 17:35:09 -0400 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9E9EB1E5; Tue, 2 Aug 2022 14:35:07 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]:53070) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oIzXb-007SMb-IA; Tue, 02 Aug 2022 15:35:03 -0600 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:48544 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oIzXa-008ty7-FF; Tue, 02 Aug 2022 15:35:03 -0600 From: "Eric W. Biederman" To: Paul Moore Cc: Martin KaFai Lau , Frederick Lawler , , , , , , , , , , , , , , , , , , , , , , , , , References: <20220721172808.585539-1-fred@cloudflare.com> <20220722061137.jahbjeucrljn2y45@kafai-mbp.dhcp.thefacebook.com> <18225d94bf0.28e3.85c95baa4474aabc7814e68940a78392@paul-moore.com> Date: Tue, 02 Aug 2022 16:33:39 -0500 In-Reply-To: <18225d94bf0.28e3.85c95baa4474aabc7814e68940a78392@paul-moore.com> (Paul Moore's message of "Fri, 22 Jul 2022 08:20:10 -0400") Message-ID: <87a68mcouk.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1oIzXa-008ty7-FF;;;mid=<87a68mcouk.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX18lynnmgZ2Re2lm2I0EfjAG9MQaqRZMbyU= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Virus: No X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Paul Moore X-Spam-Relay-Country: X-Spam-Timing: total 357 ms - load_scoreonly_sql: 0.02 (0.0%), signal_user_changed: 4.1 (1.1%), b_tie_ro: 2.8 (0.8%), parse: 0.67 (0.2%), extract_message_metadata: 11 (3.0%), get_uri_detail_list: 0.90 (0.3%), tests_pri_-1000: 32 (8.9%), tests_pri_-950: 0.99 (0.3%), tests_pri_-900: 0.82 (0.2%), tests_pri_-90: 71 (19.8%), check_bayes: 69 (19.4%), b_tokenize: 6 (1.6%), b_tok_get_all: 7 (2.0%), b_comp_prob: 1.69 (0.5%), b_tok_touch_all: 52 (14.4%), b_finish: 0.76 (0.2%), tests_pri_0: 224 (62.7%), check_dkim_signature: 0.40 (0.1%), check_dkim_adsp: 1.89 (0.5%), poll_dns_idle: 0.49 (0.1%), tests_pri_10: 2.6 (0.7%), tests_pri_500: 8 (2.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v3 0/4] Introduce security_create_user_ns() X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paul Moore writes: > On July 22, 2022 2:12:03 AM Martin KaFai Lau wrote: > >> On Thu, Jul 21, 2022 at 12:28:04PM -0500, Frederick Lawler wrote: >>> While creating a LSM BPF MAC policy to block user namespace creation, we >>> used the LSM cred_prepare hook because that is the closest hook to prevent >>> a call to create_user_ns(). >>> >>> The calls look something like this: >>> >>> cred = prepare_creds() >>> security_prepare_creds() >>> call_int_hook(cred_prepare, ... >>> if (cred) >>> create_user_ns(cred) >>> >>> We noticed that error codes were not propagated from this hook and >>> introduced a patch [1] to propagate those errors. >>> >>> The discussion notes that security_prepare_creds() >>> is not appropriate for MAC policies, and instead the hook is >>> meant for LSM authors to prepare credentials for mutation. [2] >>> >>> Ultimately, we concluded that a better course of action is to introduce >>> a new security hook for LSM authors. [3] >>> >>> This patch set first introduces a new security_create_user_ns() function >>> and userns_create LSM hook, then marks the hook as sleepable in BPF. >> Patch 1 and 4 still need review from the lsm/security side. > > > This patchset is in my review queue and assuming everything checks > out, I expect to merge it after the upcoming merge window closes. It doesn't even address my issues with the last patchset. So it has my NACK. Eric