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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35754C43334 for ; Wed, 15 Jun 2022 15:33:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B40676B0071; Wed, 15 Jun 2022 11:33:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF0616B0072; Wed, 15 Jun 2022 11:33:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 990456B0074; Wed, 15 Jun 2022 11:33:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 88E376B0071 for ; Wed, 15 Jun 2022 11:33:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 25D433528C for ; Wed, 15 Jun 2022 15:33:51 +0000 (UTC) X-FDA: 79580865462.26.187AC51 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf16.hostedemail.com (Postfix) with ESMTP id 9992D180052 for ; Wed, 15 Jun 2022 15:33:50 +0000 (UTC) Received: by mail-wm1-f46.google.com with SMTP id m16-20020a7bca50000000b0039c8a224c95so1337089wml.2 for ; Wed, 15 Jun 2022 08:33:50 -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; bh=J5eKPAN5lqKWqHRVMFEt8bECLi2YfU3n/Xvj8y2gEBE=; b=Zv2JhKlV+WgmpireahD92+ZSg2KnCdRZZvKLhjp5oxI5lNh/Plc3RXY+mQgK5+7Vg0 YcEbwmKcYO+eUdZVm8cnx1XTn3jFZkr+/y958BJAt6RHw6tO4gb/qGpriKZF4237xYW8 XdcUnlcVAybauV76RUaKKOU+9Jk1HAP8Ybq8jFsO4UP/QfChfQnRT6ZMjB1JSUkSG5A+ eeKIxvMjnfgD/uvv36ColBnfjqbtL+d7YJ45Q6RgQZkCXiULCPAF4BJO7j+EvyygfMPL eLCZ6VWgFpV+KubW52X0faomk4hEuBQnOj14ASkrNV4X772O83FKpX8IgKteHTah4Jpx 0t5Q== 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; bh=J5eKPAN5lqKWqHRVMFEt8bECLi2YfU3n/Xvj8y2gEBE=; b=f1rsR832tmzRu4ypW+DuZhuczkG7cV9yzuOHBSXjwUrm8MmVJr0LY0UJhSx8i0tjAe gebFh8PuTmPVFppdbNsHdzECwXZAKPZEa5FoxyZ0YfFf8ddVYeiQzeu4XZF7IZPxb5GX b/uL+4PNe0P5I2g7SbcHq2WK0vYcLICrfBd+bfTLf/8xMjnEOGAf5cpga67JOHjqTjaZ 5a2HadlhMBurtbd5D8/NQYrxXfhQMnEIsNriG4xFFnbQYhGCGY0268fnG65Wp4bTEceB n2OI+hQ7/y/LRV0jlafdj0E0Td+Wdc8yEA7GcC4a4qs/FYGxsxlYZHvGHBu+eK0PS/8T sqig== X-Gm-Message-State: AJIora/QfUVHn5lF8+au/S30rv83/FJl5iR0G+46b2MKkjfezfebEh5l oFM34AnRMpVfk4IdiVIb39QxfSg7b33LDmR1M948 X-Google-Smtp-Source: AGRyM1tbSXhyojX0sdqJuy36Y8CiIJerDEBwNNO0en1/SGp4CFCRbzqu86TVD3k4/Lh2/5SBr3CWSXHz2TZ3Gh292cQ= X-Received: by 2002:a05:600c:1d91:b0:39c:544b:abdd with SMTP id p17-20020a05600c1d9100b0039c544babddmr20003wms.70.1655307229181; Wed, 15 Jun 2022 08:33:49 -0700 (PDT) MIME-Version: 1.0 References: <20220608150942.776446-1-fred@cloudflare.com> <87tu8oze94.fsf@email.froward.int.ebiederm.org> <87y1xzyhub.fsf@email.froward.int.ebiederm.org> <859cb593-9e96-5846-2191-6613677b07c5@cloudflare.com> <87o7yvxl4x.fsf@email.froward.int.ebiederm.org> <9ed91f15-420c-3db6-8b3b-85438b02bf97@cloudflare.com> <20220615103031.qkzae4xr34wysj4b@wittgenstein> In-Reply-To: From: Paul Moore Date: Wed, 15 Jun 2022 11:33:38 -0400 Message-ID: Subject: Re: [PATCH v3] cred: Propagate security_prepare_creds() error code To: Ignat Korchagin Cc: Christian Brauner , "Eric W. Biederman" , Frederick Lawler , linux-doc@vger.kernel.org, linux-kernel , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-security-module@vger.kernel.org, netdev , keyrings@vger.kernel.org, selinux@vger.kernel.org, serge@hallyn.com, amir73il@gmail.com, kernel-team , Jeff Moyer Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655307230; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J5eKPAN5lqKWqHRVMFEt8bECLi2YfU3n/Xvj8y2gEBE=; b=LtP1bR0+MJIC6eaGUMWz2Jjc3ArdPz9EE0ekapwbZ3ulbmQcW9cxUgS/CiUPqvxL1RjCy5 hpE7LjTWbeEqCtiNHFFbYhDYIv9mVP5HqnESKLvAeM7YoKULnsS50BUgI7HexKVW+fzFsY wfxLq/6Z0jISLDhBu1SgqzAnC1bh2zA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=Zv2JhKlV; spf=none (imf16.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.128.46) smtp.mailfrom=paul@paul-moore.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655307230; a=rsa-sha256; cv=none; b=qJVaFR/VljSzI3T/2vp7YQcHF8lNfv8eCLt+fpdgXe+O13OBuluLf4YylXzEisFjnqC5jL H3u0tBidr4UDqJP3Di6BFjfUPuC07Vc4/tueOXC+eT+NdNFPHWQt4c1/sXIS3ejQRo4KA9 Bcgi0Mu4GLsu0Yx/18cQ2FWD0C1ORio= X-Stat-Signature: wjxzdm9hoqxj58jqsbmge4bsn8xyez4y X-Rspamd-Queue-Id: 9992D180052 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=Zv2JhKlV; spf=none (imf16.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.128.46) smtp.mailfrom=paul@paul-moore.com; dmarc=none X-HE-Tag: 1655307230-607598 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 15, 2022 at 11:06 AM Ignat Korchagin wrote: > On Wed, Jun 15, 2022 at 3:14 PM Paul Moore wrote: > > On Wed, Jun 15, 2022 at 6:30 AM Christian Brauner wrote: ... > > > Fwiw, from this commit it wasn't very clear what you wanted to achieve > > > with this. It might be worth considering adding a new security hook for > > > this. Within msft it recently came up SELinux might have an interest in > > > something like this as well. > > > > Just to clarify things a bit, I believe SELinux would have an interest > > in a LSM hook capable of implementing an access control point for user > > namespaces regardless of Microsoft's current needs. I suspect due to > > the security relevant nature of user namespaces most other LSMs would > > be interested as well; it seems like a well crafted hook would be > > welcome by most folks I think. > > Just to get the full picture: is there actually a good reason not to > make this hook support this scenario? I understand it was not > originally intended for this, but it is well positioned in the code, > covers multiple subsystems (not only user namespaces), doesn't require > changing the LSM interface and it already does the job - just the > kernel internals need to respect the error code better. What bad > things can happen if we extend its use case to not only allocate > resources in LSMs? My concern is that the security_prepare_creds() hook, while only called from two different functions, ends up being called for a variety of different uses (look at the prepare_creds() and perpare_kernel_cred() callers) and I think it would be a challenge to identify the proper calling context in the LSM hook implementation given the current hook parameters. One might be able to modify the hook to pass the necessary information, but I don't think that would be any cleaner than adding a userns specific hook. I'm also guessing that the modified security_prepare_creds() hook implementations would also be more likely to encounter future maintenance issues as overriding credentials in the kernel seems only to be increasing, and each future caller would risk using the modified hook wrong by passing the wrong context and triggering the wrong behavior in the LSM. -- paul-moore.com