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 811E7C43334 for ; Wed, 15 Jun 2022 14:14:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D3E26B0078; Wed, 15 Jun 2022 10:14:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15D676B007B; Wed, 15 Jun 2022 10:14:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F197B6B007D; Wed, 15 Jun 2022 10:14:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D705F6B007B for ; Wed, 15 Jun 2022 10:14:51 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A34EE20493 for ; Wed, 15 Jun 2022 14:14:51 +0000 (UTC) X-FDA: 79580666382.13.90AC709 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf10.hostedemail.com (Postfix) with ESMTP id F1F4EC0080 for ; Wed, 15 Jun 2022 14:14:50 +0000 (UTC) Received: by mail-wr1-f43.google.com with SMTP id h19so12340172wrc.12 for ; Wed, 15 Jun 2022 07:14: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=TmFspR35i19OaG7kIq4BfP3Z5+5KHooJY8o+wf2Eu7g=; b=hnjS0y0DJB+Pgxck/o6M0KR1CyJPsNohu8wEV1ngzYEvfR3BNgdCgc8bBCjYcSn/q2 LGrABHBIuN5wiJVr3vFBZSQoyuo+ow5O4zy8y+xuerraxDm52W00Ql6GN8mxJBK7Aged DMepzdaFMPS1SBM8wU0DjvHn5zjVaCWGHNtmseACjEovZd9TfrOheGRLWXnnpvnFbk3L Oh5JBbb6A+TcxaBr62FlW4W2kMYFlFl4qBPFa5Vljf/kfuiWpPulvsvFhKfMVnlp7H1I /Ewf9GWseGoqqzdlh7+S2YPdnfxgjB6XJIAkXpRzobHf9nGOIaKrkjPQFKm48HdjqWaG xCzw== 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=TmFspR35i19OaG7kIq4BfP3Z5+5KHooJY8o+wf2Eu7g=; b=4FP5mp3T3xxasPL8dIoEUNZ0P6fmBCGu1ePUDX9sXMi6myEYmhScWz2N2y09Adaa+w 4hlgLMVybbMP4x8/owwtajdgME75uc9XhJ9r2RZA5VvtWzRZiKZx8HOuhI72ypy9WNMs fwyhsFmEm9KVgLnlMmHE7PmgxcldRkYfCm6PwiDN0nY4vNsfOS/pMldl7X249aAzXhbH b+J6KqplZYd8CersF/GvsnZQ5h3UHACSLyC7oQoeBK4yROZUZab3ne8z25Zll/hL+dXi hwbzT26b4wUgprFEv6BFXOvN8eQTvkR0VEHcBF7arCdR/orEiOSFED4X7n+EkW0Vdgh5 Gddg== X-Gm-Message-State: AJIora+3MmsIHrf2HTqhH9CBZtpqebmejQmGjY1P9EfR5JqjvaZY9go6 UjOxkOpifsUUs7T3xxcCNT54ls2QNnaCvggho0H4 X-Google-Smtp-Source: AGRyM1shZLCqZkkSojukqCXaW+5XT6IN8fQuWUaigb52d2YijY5GHtpeOYg1i3lr6LTItEcWJJFmcKwvqWFcwysL51U= X-Received: by 2002:a05:6000:1447:b0:21a:278a:181c with SMTP id v7-20020a056000144700b0021a278a181cmr27393wrx.161.1655302489487; Wed, 15 Jun 2022 07:14: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: <20220615103031.qkzae4xr34wysj4b@wittgenstein> From: Paul Moore Date: Wed, 15 Jun 2022 10:14:38 -0400 Message-ID: Subject: Re: [PATCH v3] cred: Propagate security_prepare_creds() error code To: Christian Brauner Cc: Frederick Lawler , "Eric W. Biederman" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 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@vger.kernel.org, keyrings@vger.kernel.org, selinux@vger.kernel.org, serge@hallyn.com, amir73il@gmail.com, kernel-team@cloudflare.com, 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=1655302491; 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=TmFspR35i19OaG7kIq4BfP3Z5+5KHooJY8o+wf2Eu7g=; b=3nFkDqn4jHGyGAo3XM0L5WNfzwNmnTVqpSRhYQRBIFzoUufyNY2dHJXg6vgAqySuKYlDpp dZKJmOZXotOAjueXjBTpatUSDSvI3hBTWzYa6/XJaiWVWhkuXQWr+criay79ec3gcCnyVc 5xNbJNSICZaKfDcp2B7JNAddRAE6Brs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=hnjS0y0D; spf=none (imf10.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.221.43) smtp.mailfrom=paul@paul-moore.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655302491; a=rsa-sha256; cv=none; b=hn1OY96lobI0roKeKANVjmCubeHTnClcqrZMze4RQ/XJGw0Uwydk9IJ/OG6B7TRG5gFsog yeflRRovyUzNAq4UXBwanR72Yr70zk45pKUqCWl2kSPphGyV60GAQRuRjvXYdUuHqFGbGq 9Xbp94y/2u9GbrbdFvkO8g3U2DzcI1s= X-Stat-Signature: owejqbmc7gsn8nhd8mzrcew9b4kjojeb X-Rspamd-Queue-Id: F1F4EC0080 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=hnjS0y0D; spf=none (imf10.hostedemail.com: domain of paul@paul-moore.com has no SPF policy when checking 209.85.221.43) smtp.mailfrom=paul@paul-moore.com; dmarc=none X-HE-Tag: 1655302490-591348 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 6:30 AM Christian Brauner wrote: > > On Tue, Jun 14, 2022 at 01:59:08PM -0500, Frederick Lawler wrote: > > On 6/14/22 11:30 AM, Eric W. Biederman wrote: > > > Frederick Lawler writes: > > > > > > > On 6/13/22 11:44 PM, Eric W. Biederman wrote: > > > > > Frederick Lawler writes: > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > On 6/13/22 12:04 PM, Eric W. Biederman wrote: > > > > > > > Frederick Lawler writes: > > > > > > > > > > > > > > > While experimenting with the security_prepare_creds() LSM hook, we > > > > > > > > noticed that our EPERM error code was not propagated up the callstack. > > > > > > > > Instead ENOMEM is always returned. As a result, some tools may send a > > > > > > > > confusing error message to the user: > > > > > > > > > > > > > > > > $ unshare -rU > > > > > > > > unshare: unshare failed: Cannot allocate memory > > > > > > > > > > > > > > > > A user would think that the system didn't have enough memory, when > > > > > > > > instead the action was denied. > > > > > > > > > > > > > > > > This problem occurs because prepare_creds() and prepare_kernel_cred() > > > > > > > > return NULL when security_prepare_creds() returns an error code. Later, > > > > > > > > functions calling prepare_creds() and prepare_kernel_cred() return > > > > > > > > ENOMEM because they assume that a NULL meant there was no memory > > > > > > > > allocated. > > > > > > > > > > > > > > > > Fix this by propagating an error code from security_prepare_creds() up > > > > > > > > the callstack. > > > > > > > Why would it make sense for security_prepare_creds to return an error > > > > > > > code other than ENOMEM? > > > > > > > > That seems a bit of a violation of what that function is supposed to do > > > > > > > > > > > > > > > > > > > The API allows LSM authors to decide what error code is returned from the > > > > > > cred_prepare hook. security_task_alloc() is a similar hook, and has its return > > > > > > code propagated. > > > > > It is not an api. It is an implementation detail of the linux kernel. > > > > > It is a set of convenient functions that do a job. > > > > > The general rule is we don't support cases without an in-tree user. I > > > > > don't see an in-tree user. > > > > > > > > > > > I'm proposing we follow security_task_allocs() pattern, and add visibility for > > > > > > failure cases in prepare_creds(). > > > > > I am asking why we would want to. Especially as it is not an API, and I > > > > > don't see any good reason for anything but an -ENOMEM failure to be > > > > > supported. > > > > > > > > > We're writing a LSM BPF policy, and not a new LSM. Our policy aims to solve > > > > unprivileged unshare, similar to Debian's patch [1]. We're in a position such > > > > that we can't use that patch because we can't block _all_ of our applications > > > > from performing an unshare. We prefer a granular approach. LSM BPF seems like a > > > > good choice. > > > > > > I am quite puzzled why doesn't /proc/sys/user/max_user_namespaces work > > > for you? > > > > > > > We have the following requirements: > > > > 1. Allow list criteria > > 2. root user must be able to create namespaces whenever > > 3. Everything else not in 1 & 2 must be denied > > > > We use per task attributes to determine whether or not we allow/deny the > > current call to unshare(). > > > > /proc/sys/user/max_user_namespaces limits are a bit broad for this level of > > detail. > > > > > > Because LSM BPF exposes these hooks, we should probably treat them as an > > > > API. From that perspective, userspace expects unshare to return a EPERM > > > > when the call is denied permissions. > > > > > > The BPF code gets to be treated as a out of tree kernel module. > > > > > > > > Without an in-tree user that cares it is probably better to go the > > > > > opposite direction and remove the possibility of return anything but > > > > > memory allocation failure. That will make it clearer to implementors > > > > > that a general error code is not supported and this is not a location > > > > > to implement policy, this is only a hook to allocate state for the LSM. > > > > > > > > > > > > > That's a good point, and it's possible we're using the wrong hook for the > > > > policy. Do you know of other hooks we can look into? > > 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. -- paul-moore.com