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 2BD47CCA483 for ; Wed, 20 Jul 2022 22:39:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230504AbiGTWjV (ORCPT ); Wed, 20 Jul 2022 18:39:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230490AbiGTWjT (ORCPT ); Wed, 20 Jul 2022 18:39:19 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA5EE2F3AF for ; Wed, 20 Jul 2022 15:39:17 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id bk26so28044665wrb.11 for ; Wed, 20 Jul 2022 15:39:17 -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=gjQxo0hKIVF1YVkSJ8Tt3ejloLl3VpIsO9hirXnFH+U=; b=zI4b6Z/wGUUgwWeOD3pQ7dMozzrzLOSSr5UB4/ki36H/h/zC0Qb1NCR/RhxeQdHB+Z 3FCKUbPYT5+bU3pmhLvpKxSDvhXulocHKjQJIK9p2OWuINXr0ivOwxxFVq8r2AsYJL0k h2jIEJlNGTvnLKbR2B1DBtIZIcqD7gzg4o3ocXh3FpoC1frMzUOTzgFrhv924XvD3qy6 bGkXIyFJEC3lxyxyiCQL50o2Lakud4qBn1yd2/Ofteeaj17Q+3Q2Y9JWICUkKp2nG3tu nmWKI3COxvtxiKvkkyvYG9tb5TN1DQ3EJhT9fkaryBkGsfd6tZY/Q5QUvQapNTufNH1C bPlA== 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=gjQxo0hKIVF1YVkSJ8Tt3ejloLl3VpIsO9hirXnFH+U=; b=YCSwksozi2/K9EV7YxuZl3HPWT/+f8b8xbFcTA+WR2/YRqYLsPdVnOD8vjPP2X6UuG sOfIf4lolp1cthANKF8QT4XfZSHyjLGGDZU/5XKGvGEmaESKwka5L1Ce/3OE4C1FDhIs 4qZFdKTXsGGHLvOR05Z6T978Bl9shc3obrnsziwYKBSIL83YbQMpNjsXsPQMncJ+s8D6 K2lPO8RCyFfRMqA8K8JLYPrlbhw5amXMnV0rZVnhbNfr6nQxTTJ/nrgmjb1sk2Os9V7J AyTXCB192JaW+Qgdz73jcBgpxHKWd0RCXdSII6I8ClH9KV0VMQBCx2zi4nx4QOxwOVPN xa6g== X-Gm-Message-State: AJIora+gFvCOXgppnJIHBL18f/yCqyCihP649N223V6BAc6T1dks7Blf 8ckph1Mo1FYGlE1JGu/uwhFaBaR4JDxXluLF7oxg X-Google-Smtp-Source: AGRyM1tdrjUF8cXJwhaIP6PHYKjrB2YVUyMErv5SbIcoUCr7yadS90weIQu40rllAkj9qSRNkrh4MkilhnWcTexYRQo= X-Received: by 2002:adf:e492:0:b0:21e:45af:5070 with SMTP id i18-20020adfe492000000b0021e45af5070mr5887107wrm.483.1658356756213; Wed, 20 Jul 2022 15:39:16 -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: From: Paul Moore Date: Wed, 20 Jul 2022 18:39:05 -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 Wed, Jul 20, 2022 at 5:42 PM Casey Schaufler wr= ote: > On 7/19/2022 6:32 PM, Paul Moore wrote: > > On Fri, Jul 8, 2022 at 12:11 PM Casey Schaufler wrote: > >> 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: ... > >>>> 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 namesp= ace > >> efforts. SELinux, Smack and AppArmor have all developed namespace mode= ls. > > > > 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"? > > Stephen Smalley proposed a SELinux namespace model, with patches, > some time back. It hasn't been adopted, but I've seen at least one > attempt to revive it. You're right that there isn't an established > model. If it isn't in the mainline kernel, it isn't an established namespace model= . I ported Stephen's initial namespace patches to new kernels for quite some time, look at the working-selinuxns branch in the main SELinux repository, but that doesn't mean they are ready for upstreaming. Aside from some pretty critical implementation holes, there is the much larger conceptual issue of how to deal with persistent filesystem objects. We've discussed that quite a bit among the SELinux developers but have yet to arrive at a good-enough solution. I have some thoughts on how we might be able to make forward progress on that, but it's wildly off-topic for this patchset discussion. I mostly wanted to make sure I was understanding what you were referencing when you talked about a "SELinux namespace model", and it is what I suspected ... which I believe is unrelated to the patches being discussed here. > >> That, or it could replace the various independent efforts with a singl= e, > >> 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. > > It's possible that fresh eyes might see options that those who have > been staring at the current state and historical proposals may have > missed. That's always a possibility, and I'm definitely open to a clever approach that would resolve all the current issues and not paint us into a corner in the future, but I haven't seen anything close (or any serious effort for that matter). ... and this still remains way off-topic for a discussion around adding a hook to allow LSMs to enforce access controls on user namespace creation. > > 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. > > Possibly. On the other hand, if someone came up with a rational scheme > for general xattr namespacing I don't see that anyone would pass it up. Oh geez ... Namespacing xattrs is not the same thing as namespacing LSMs. LSMs may make use of xattrs, and namespacing xattrs may make it easier to namespace a given LSM, but I'm not aware of an in-tree LSM that would be magically namespaced if xattrs were namespaced. This patchset has nothing to do with xattrs, it deals with adding a LSM hook to implement LSM-based access controls for user namespace creation. --=20 paul-moore.com