From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DFEF1863 for ; Wed, 28 Dec 2022 15:06:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D71D3C433D2; Wed, 28 Dec 2022 15:06:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1672240018; bh=rnj2D8Gu4UrcFf3KpzZLWCSLRUJj0Yb9goAZhYSmhXU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sDZZyVpOiX87Pt6iy1Rr2XHq6tlAbpa5BI0rG+FB4Rqbz0BX0oChUGIzOLWiemPxi FZolOb1MswfpYR7VcMwBZzf0wFwAJY7mKVB2KQJUcDjzhgzsbaZ73/RYVA0vfSKO4x y9w1fmN4ELgT1AYMMyTM/hHfjV30Czd4KRO+WFW4= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Martin Pitt , "Christian Brauner (Microsoft)" , Ondrej Mosnacek , Paul Moore , Sasha Levin Subject: [PATCH 6.0 0108/1073] fs: dont audit the capability check in simple_xattr_list() Date: Wed, 28 Dec 2022 15:28:16 +0100 Message-Id: <20221228144330.976270445@linuxfoundation.org> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20221228144328.162723588@linuxfoundation.org> References: <20221228144328.162723588@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ondrej Mosnacek [ Upstream commit e7eda157c4071cd1e69f4b1687b0fbe1ae5e6f46 ] The check being unconditional may lead to unwanted denials reported by LSMs when a process has the capability granted by DAC, but denied by an LSM. In the case of SELinux such denials are a problem, since they can't be effectively filtered out via the policy and when not silenced, they produce noise that may hide a true problem or an attack. Checking for the capability only if any trusted xattr is actually present wouldn't really address the issue, since calling listxattr(2) on such node on its own doesn't indicate an explicit attempt to see the trusted xattrs. Additionally, it could potentially leak the presence of trusted xattrs to an unprivileged user if they can check for the denials (e.g. through dmesg). Therefore, it's best (and simplest) to keep the check unconditional and instead use ns_capable_noaudit() that will silence any associated LSM denials. Fixes: 38f38657444d ("xattr: extract simple_xattr code from tmpfs") Reported-by: Martin Pitt Suggested-by: Christian Brauner (Microsoft) Signed-off-by: Ondrej Mosnacek Reviewed-by: Christian Brauner (Microsoft) Reviewed-by: Paul Moore Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Sasha Levin --- fs/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xattr.c b/fs/xattr.c index a1f4998bc6be..8ea6b104b106 100644 --- a/fs/xattr.c +++ b/fs/xattr.c @@ -1147,7 +1147,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size, ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs, char *buffer, size_t size) { - bool trusted = capable(CAP_SYS_ADMIN); + bool trusted = ns_capable_noaudit(&init_user_ns, CAP_SYS_ADMIN); struct simple_xattr *xattr; ssize_t remaining_size = size; int err = 0; -- 2.35.1