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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26C2EC43334 for ; Wed, 20 Jul 2022 01:41:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242250AbiGTBlc (ORCPT ); Tue, 19 Jul 2022 21:41:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241767AbiGTBlE (ORCPT ); Tue, 19 Jul 2022 21:41:04 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 131057AC36 for ; Tue, 19 Jul 2022 18:32:44 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id f24-20020a1cc918000000b003a30178c022so387345wmb.3 for ; Tue, 19 Jul 2022 18:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tQp/N6Uk+UKd7eDu5UmzGuGhmF0Y+ibaoFPpIegLF+Y=; b=by6T/E8VkX8oFtD8dnsR64IT7UFDcrTPCAIRCgOPa/LJUI8JOCFbfiz7J364/bCOeH rd2SkAx8XnmkmyymE0WIWkYVOzMHAWDtTOM7/pu4iS/Fe00JFXhg564o71FrfrqpBCLX kNQx4x/jPUrpwvMLbAB7FQyDSSJU5xbxfQ3JJ8oycJgKPUTeAw2TRAoGo85orXqi0A8u Xs58+Hntk7L9VAArrtF/7CD3yaGAuk+/qXl0aNv10D0zU/SEvOHRpjy0Q2PZ1bdEhEgl 88w2QZanxV32ADu69Bwbh0ecfaxCfSbzFZyoWEIAXF445J3pol4ru5Qh5EMeLZvIwOIM TLcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tQp/N6Uk+UKd7eDu5UmzGuGhmF0Y+ibaoFPpIegLF+Y=; b=3ktGmPGd/PgJq8JpOfcokAL0vxY0PQuAQH+gPM98y+uxPV+jm0UdiGaIAcGBI9E7v1 1uySGhtIz3zBtVIYDf18+p1Y+2h5EKHQxvJ5ympo0MxsPCaHmHIPRlyFyRLOJfNrMQFJ j5xMunmrW9GroGvViqDbGRyr22uaj3HZ8+yRvJPqti9cp4tXCkrypVysQfKujhCZ0diH /fleRaCO3ctEuhY1jODnJLMrGV/dm0V0XJUVnqcqbQhnPHhk4umqoRrCFeEmBvm5sPfz RLhyMsvu9mgoByhwc6u+4gTSQ7q0jGJ7O7adRNoMrokHrgShP8STaQMweFeT4u5CfiWP CGIg== X-Gm-Message-State: AJIora/a/GPp6C/H5sNOm8OPKGcGLz4Nre+H5ZwPxi8+ST7pCGSmk8+H Fu38IVeMUzztcZQigP282yV9NoRYtzKzLxcWiTem X-Google-Smtp-Source: AGRyM1ubeyz5pphxIFoknkif5zSYvGormRenvsTvDWi7UK6OclfHHNS+LtozRpPhZOyHN270g6dMP5377DarcQ4fJ5w= X-Received: by 2002:a7b:ce8f:0:b0:3a2:ff2d:915f with SMTP id q15-20020a7bce8f000000b003a2ff2d915fmr1512608wmj.165.1658280762556; Tue, 19 Jul 2022 18:32:42 -0700 (PDT) MIME-Version: 1.0 References: <20220707223228.1940249-1-fred@cloudflare.com> <3dbd5b30-f869-b284-1383-309ca6994557@cloudflare.com> <84fbd508-65da-1930-9ed3-f53f16679043@schaufler-ca.com> In-Reply-To: <84fbd508-65da-1930-9ed3-f53f16679043@schaufler-ca.com> From: Paul Moore Date: Tue, 19 Jul 2022 21:32:31 -0400 Message-ID: Subject: Re: [PATCH v2 0/4] Introduce security_create_user_ns() To: Casey Schaufler Cc: Frederick Lawler , =?UTF-8?Q?Christian_G=C3=B6ttsche?= , KP Singh , revest@chromium.org, jackmanb@chromium.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , shuah@kernel.org, Christian Brauner , "Eric W. Biederman" , bpf@vger.kernel.org, linux-security-module@vger.kernel.org, SElinux list , linux-kselftest@vger.kernel.org, Linux kernel mailing list , netdev@vger.kernel.org, kernel-team@cloudflare.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Fri, Jul 8, 2022 at 12:11 PM Casey Schaufler wr= ote: > On 7/8/2022 7:01 AM, Frederick Lawler wrote: > > On 7/8/22 7:10 AM, Christian G=C3=B6ttsche wrote: > >> ,On Fri, 8 Jul 2022 at 00:32, Frederick Lawler > >> wrote: ... > >> Also I think the naming scheme is _. > > > > That's a good call out. I was originally hoping to keep the > > security_*() match with the hook name matched with the caller function > > to keep things all aligned. If no one objects to renaming the hook, I > > can rename the hook for v3. No objection from me. [Sorry for the delay, the last week or two has been pretty busy.] > >> III. > >> > >> Maybe even attach a security context to namespaces so they can be > >> further governed? > > That would likely add confusion to the existing security module namespace > efforts. SELinux, Smack and AppArmor have all developed namespace models. I'm not sure I fully understand what Casey is saying here as SELinux does not yet have an established namespace model to the best of my understanding, but perhaps we are talking about different concepts for the word "namespace"? >From a SELinux perspective, if we are going to control access to a namespace beyond simple creation, we would need to assign the namespace a label (inherited from the creating process). Although that would need some discussion among the SELinux folks as this would mean treating a userns as a proper system entity from a policy perspective which is ... interesting. > That, or it could replace the various independent efforts with a single, > unified security module namespace effort. We've talked about this before and I just don't see how that could ever work, the LSM implementations are just too different to do namespacing at the LSM layer. If a LSM is going to namespace themselves, they need the ability to define what that means without having to worry about what other LSMs want to do. -- paul-moore.com