From patchwork Sun Mar 2 16:06:48 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997884 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 359A61EE7AB; Sun, 2 Mar 2025 16:07:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931642; cv=none; b=sYK2Cm/AbMV6D5dm7naDkdBBnuEW8wARnLQZQKTsGr3Y1G4zLaA0xi5DNlAPaRNy0IETpPlBFRFqJRHrmMrc9JjoM9pBnAKGEsTtwZF5FvGv/Ug0/DWwdeQ4Bf10xGRovTRBtKcG+f6fvdl5RoN140u+JwqZGgvz1T8ZFwera2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931642; c=relaxed/simple; bh=q4kLq85gsyUAnl8du8+7CG1shloC+EIB+wENgTVQN6c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lCZWdIolro01pbhEx5QML0pFISLw12mqvGmv1L7abV4sQ4Oo+EeB7xHTaRFGjtH0RGgKp3JLv52CsA7wEoLxu7bZ1qqCzkhI2gfeWMEvko+LQvnrd5b2P8Ms/QZQgQfdltdvKs4+D4PF5/SKIuMbBbnjiPCSTyZQtIRSSH6jM3c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=I8Us6+ww; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="I8Us6+ww" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931638; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DocaNsuHjM+N41rLqaAWsZ7H9Gb/g9wp09AAVVo026g=; b=I8Us6+wwEBsSw3c/3WEDogDmTjcrUN78W4pRQk/r8mUCE4HL31uoClsJaAivN/3V/6XqD8 BADNH6reL9sZ1mS76cvitfZJDq3G1BGl+enF4gm2K8k32JUnxEyAUcqOxUGsmrOA1D17BU j2QbCRtr+f0eRBa9AGgDd63jkxRchptmeA4Al/MXKqCbWsQar+koAeeJtx/zXrtfUPIdyM vWfOfR2T8mkQ84ROq/wPTQdQbX6HOzsQBKMTC3V4XgBydnCuO05Lg5hslRvQBmxn56F5OE jZ7z+rIuMwFKWRm4XYAEEFsV7U6Vfxk9y/J4DSWMND/c+kbkc34Hf3CVBRSG4w== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr Subject: [PATCH v2 01/11] coccinelle: Add script to reorder capable() calls Date: Sun, 2 Mar 2025 17:06:48 +0100 Message-ID: <20250302160657.127253-11-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- MAINTAINERS | 1 + scripts/coccinelle/api/capable_order.cocci | 98 ++++++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 scripts/coccinelle/api/capable_order.cocci diff --git a/MAINTAINERS b/MAINTAINERS index 8e0736dc2ee0..b1d1c801765b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5196,6 +5196,7 @@ F: include/linux/capability.h F: include/trace/events/capability.h F: include/uapi/linux/capability.h F: kernel/capability.c +F: scripts/coccinelle/api/capable_order.cocci F: security/commoncap.c CAPELLA MICROSYSTEMS LIGHT SENSOR DRIVER diff --git a/scripts/coccinelle/api/capable_order.cocci b/scripts/coccinelle/api/capable_order.cocci new file mode 100644 index 000000000000..4150d91b0f33 --- /dev/null +++ b/scripts/coccinelle/api/capable_order.cocci @@ -0,0 +1,98 @@ +// SPDX-License-Identifier: GPL-2.0-only +/// +/// Checks for capable() calls of the left side of a binary expression. +/// Reordering might avoid needless checks, LSM log messages, and more +/// restrictive LSM security policies (e.g. SELinux). +/// Can report false positives if the righthand side contains a nested +/// capability check or has side effects. +/// +// Confidence: Moderate +// Copyright: (C) 2024 Christian Göttsche. +// Options: --no-includes --include-headers +// Keywords: capable, ns_capable, sockopt_ns_capable +// + +virtual patch +virtual context +virtual org +virtual report + +//---------------------------------------------------------- +// Pattern to ignore +//---------------------------------------------------------- + +@ignore@ +identifier F1 = { capable, ns_capable, sockopt_ns_capable }; +identifier F2 = { capable, ns_capable, sockopt_ns_capable }; +binary operator op,op1,op2; +expression E; +position p; +@@ + +( +F1@p(...) op F2(...) +| +E op1 F1@p(...) op2 F2(...) +) + + +//---------------------------------------------------------- +// For patch mode +//---------------------------------------------------------- + +@ depends on patch@ +identifier F = { capable, ns_capable, sockopt_ns_capable }; +binary operator op,op1,op2; +expression E,E1,E2; +expression list EL; +position p != ignore.p; +@@ + +( +- F@p(EL) op E ++ E op F(EL) +| +- E1 op1 F@p(EL) op2 E2 ++ E1 op1 E2 op2 F(EL) +) + + +//---------------------------------------------------------- +// For context mode +//---------------------------------------------------------- + +@r1 depends on !patch exists@ +identifier F = { capable, ns_capable, sockopt_ns_capable }; +binary operator op,op1,op2; +expression E, E1, E2; +position p != ignore.p; +@@ + +( +* F@p(...) op E +| +* E1 op1 F@p(...) op2 E2 +) + + +//---------------------------------------------------------- +// For org mode +//---------------------------------------------------------- + +@script:python depends on org@ +p << r1.p; +@@ + +cocci.print_main("WARNING opportunity for capable reordering",p) + + +//---------------------------------------------------------- +// For report mode +//---------------------------------------------------------- + +@script:python depends on report@ +p << r1.p; +@@ + +msg = "WARNING opportunity for capable reordering" +coccilib.report.print_report(p[0], msg) From patchwork Sun Mar 2 16:06:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997874 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 A1CF51E9B20; Sun, 2 Mar 2025 16:07:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931627; cv=none; b=Ybb3qzCCWZiXML6Axp89w7i4oIPUlJIBQmdemEEfUVJIxz7fG4slO6d8l3ir170x5mps2P0ZVx+dH9b+cp9OeeR3gK+9dX3ktfnxga918L8sbYTlAXb80HTebUJcE3BLT9YV8YJ+q8X4lK/NK6y9jhmGYMuWQaqL0tmRbk+AR1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931627; c=relaxed/simple; bh=Jl1OONU/HPYf7/P1zk30SJXk1bcmft8tcRaTvFtTY6Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=QApefA4HTuoAd9f0AJBi7RhALpr+Bkm4WoLrwG5rFW1BXluK5xtAjHKpLsqPNDmMqtbsIvcM2QOlGxnQ5UDxlAyqa9PC0H0OgE8N0Zp9Fs1rtV+pUBZnfrA0syt+WYmvGxDDmAj2gavKUGxnsfkRC0m166Lx8usprUH1LT9S6/Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=PiWSfiie; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="PiWSfiie" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931622; h=from:from:reply-to: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:content-transfer-encoding; bh=O6DE7DCpJw4TB8feyeSd8BWfUFVAmf0EuvvRwHMeulI=; b=PiWSfiieggVS+NN774Yowdm3BHp08bxuRLv4yBIU7WPvptO1S3gmmiHLeYXYmtpJQbuxHE tl+oUyQ+zI2i7B8Fn2bEToyS9YLGcjJU2dHkRupFBaT4ALGWcaV8pJowicqwQQlvB2W4ql MxoMfrj07KDalLy6DIrunO6hBwM8CcszdwW65tv2rj1krx1nyFWPyI4gvzcL9r7FVn78E/ jlYF4VMCNL/G7PK40V/u0UhZOFkGs/jnixY6Rm+Q0yggOaJszuLy5jRKKljTFboNhwyxMX spm1dWYccPY499VqDlbImT/va1d+AtfepabQe8ew7e7bZ+uTckZrB8diqJ8DEg== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr Subject: [PATCH v2 02/11] quota: reorder capability check last Date: Sun, 2 Mar 2025 17:06:38 +0100 Message-ID: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- fs/quota/dquot.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index 825c5c2e0962..5c56babf581c 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -1283,9 +1283,9 @@ static int ignore_hardlimit(struct dquot *dquot) { struct mem_dqinfo *info = &sb_dqopt(dquot->dq_sb)->info[dquot->dq_id.type]; - return capable(CAP_SYS_RESOURCE) && - (info->dqi_format->qf_fmt_id != QFMT_VFS_OLD || - !(info->dqi_flags & DQF_ROOT_SQUASH)); + return (info->dqi_format->qf_fmt_id != QFMT_VFS_OLD || + !(info->dqi_flags & DQF_ROOT_SQUASH)) && + capable(CAP_SYS_RESOURCE); } static int dquot_add_inodes(struct dquot *dquot, qsize_t inodes, From patchwork Sun Mar 2 16:06:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997875 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 084AF1E3761; Sun, 2 Mar 2025 16:07:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931628; cv=none; b=tX7btjRylkYHryrA+Ejyp8zo6WdZwwxamCP6/iIqVnsrFuEVDJVtHUfutqHE80tG+L5zFkt+1xvpDLeQIFuUMhORI+opBvgmu9crTStYsqONzvktAOlvt8dLUWMLbko27nDQzSZoJkKdOHGOyj8SA9g5vhs7Lblmpi8QmY1NM+g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931628; c=relaxed/simple; bh=DwoObYbkc3t6mMKbabMcq7AMLtAfZbBxFbz7lxK4ZC8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=F0X1s326fOv402WmZZ+Ta8A0sGCVEhCp3KPohGLIHcLKw+HaYSWMSbw8GCs0I0yW5su1GD4WXHYiEx6ne1BD5mmadoTFPhjv60HRDmRz6vD55yZiOMjBkcuoIa9uH8l7Dx5p7s/lWlL/7AIbgJrepd+ZMSInPxy831cIpGfxSZc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=rW723r6b; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="rW723r6b" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931624; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LtVFyKPYvAG6nPAlnlSRsIED7/Fit5RjlOi+m21VZYs=; b=rW723r6bWSv6qn26AEbrStX87CkVu9G/7vNGrh7xh7Lqn7pp5kWJbhTClYidy6wk+Y+7sd FjPR7nS2CFldQESu5vxVqQRKbzDULfHYgaqGYBjNrElC8Jp/+8E5Ctfj1Nv59jeyJqvS98 yhpZrwB0FKmtPiiVuoqWjkBdcS/5eOoj5FPfR9gm5C7XWNjjza4nuEYR9IxTQ0lpuWjwCZ e+OlRPH2PFwomxohnhpClrlM995TmC9Xbrwm+7wdfa0h0OYtxXTqP8FO7MHjgM164WRD/j 93uAuVblah5062CFYFw/SQT9UgQc9mpRBtCUpTLTwBR1k7kbipwv85mDQlL9vg== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, "Theodore Ts'o" , Andreas Dilger , linux-ext4@vger.kernel.org Subject: [PATCH v2 03/11] ext4: reorder capability check last Date: Sun, 2 Mar 2025 17:06:39 +0100 Message-ID: <20250302160657.127253-2-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- fs/ext4/balloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 8042ad873808..c48fd36b2d74 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -649,8 +649,8 @@ static int ext4_has_free_clusters(struct ext4_sb_info *sbi, /* Hm, nope. Are (enough) root reserved clusters available? */ if (uid_eq(sbi->s_resuid, current_fsuid()) || (!gid_eq(sbi->s_resgid, GLOBAL_ROOT_GID) && in_group_p(sbi->s_resgid)) || - capable(CAP_SYS_RESOURCE) || - (flags & EXT4_MB_USE_ROOT_BLOCKS)) { + (flags & EXT4_MB_USE_ROOT_BLOCKS) || + capable(CAP_SYS_RESOURCE)) { if (free_clusters >= (nclusters + dirty_clusters + resv_clusters)) From patchwork Sun Mar 2 16:06:40 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997876 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 ECD041E7C32; Sun, 2 Mar 2025 16:07:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931629; cv=none; b=LTkhffUlUO81UJpt29xuZXKkpK5mrtC9GEHYQ4JUUlw7g6PjZ2eSXMSv6tSFTv3PVVasczjquY9zwnxbPYIoVI88qbe0guMRb6ak6MPxkL5CoDGt7kCueU2hgWhI6yGRNLkGMxuKw8Uz+VDDLhhH2RugU/1r1UnannoDBAHvwQs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931629; c=relaxed/simple; bh=OLtEwpQ7kc/v2nO4iZrLWQivq+0Sn82iOiuaRwES+s8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cP4vh+qKsWYNu9yLzgpPg2GDPTl4ta9/VlF7IJDNhsDYUAVQHI6wPE9AVmTYBS5N+8S1avtaqX64yNGH7pq3jMa0TLNMfRbf+8QvsLyPMXwroWGDBgSGYXq0q3As2ZwPoD2/nB3aOQ1/yEqSWn5a6+DVdq4+wtTwV3edYOTw0Bk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=SdoKH+0E; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="SdoKH+0E" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931625; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=psW6cnDKJDfMxUnzR9ln5khjNnX+9pHtPh2iqMJCG30=; b=SdoKH+0EzYCBj4vtLHksHZyyUfjYZYKyFPGkljGjoi+IHVmwQJ3uge+Qp04jAU2zNFI1/r Dekh52KkrWPJJMvDFFExflW3hppm4mZV0sc15sZZK2HTv6+l5y3KhSCzHU3A5o3qYyULJv MZwMwXtHFShVOr28DbUn+7Ftijj5pjZb7fJH/BtLcuuvkqUnFqwiabiztFppznggEGbSmA 6hd3QK1owK3/DJH0JeVy9v3vUAT3hZv04FH+cEaTKd7APURmHNhTWRbHEhkSKYohna2m0j Ej2/5LFCvfcNkzt4mOEXcBtGX4Dy+dqNKXoJTGBtjw9zV0U+RefdjINmHf0O+Q== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Muchun Song , linux-mm@kvack.org Subject: [PATCH v2 04/11] hugetlbfs: reorder capability check last Date: Sun, 2 Mar 2025 17:06:40 +0100 Message-ID: <20250302160657.127253-3-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- fs/hugetlbfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 0fc179a59830..e36b0e6df720 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1503,7 +1503,7 @@ static int can_do_hugetlb_shm(void) { kgid_t shm_group; shm_group = make_kgid(&init_user_ns, sysctl_hugetlb_shm_group); - return capable(CAP_IPC_LOCK) || in_group_p(shm_group); + return in_group_p(shm_group) || capable(CAP_IPC_LOCK); } static int get_hstate_idx(int page_size_log) From patchwork Sun Mar 2 16:06:41 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997877 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 9A1101E9B36; Sun, 2 Mar 2025 16:07:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931630; cv=none; b=aVO2YBkNHgXFTDWKw/DlF9h1ndWhw9oVr6swwKhQPB0fCtMxs0yWI6gVeXSOCOG56H1TkkQFBxyAtSuhb1cGYUTYXWUctVwIeD5ZrLCEsKGvffpvtF3cuyGB5mwcmiWxnkqPltkdLB4FTzDo1V7InprLnVaMwJNtiaNDe9PtIsw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931630; c=relaxed/simple; bh=W6Ib8SUnJ1JU0HiaqnjJwSX+UKJG2AFtodiU7/gTTFI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ekwFxYQXKWE2zKt3ly3ofRWW1/LznRNNfp4F/RUY7UGRwmnCQfbuW04KPq/gGNtpmbyPWxN9k3XnRZjqp5kupwfrocbp1L39PmWkST4qyDvFyBZZcF9C6kXmo7drMqg/6kc9XdbyqKRJG/oIjCNlJ23TCR/MocYsyw/sjWR5N+c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=pNCwjOEA; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="pNCwjOEA" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931626; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XAjxnHbZt7O2sowQljNKhNG6jmP0PgDVtJXqvuqsprc=; b=pNCwjOEAHKlzf0wE7LNZ87/QTHMW/pzQfLR1ATk2Ir4ezHhvcADFFZmbdNhV22pWG8HcCD UIAFzWvW6DIsCoOJwqRdJqoRALQz/oK7FqTQ6CdEk66UJOSU9wGQsq2k3QRI2b4wiWlu55 GFSk8k+/WGXnC/W7V9dk0Rd2SyJ7OzobelL8Ji4fIrW3inxWGmd6FFLzjXe919hLwq1Ew3 4mEuWbkAZEHR0Qv4Uau5S7L3j2BDRtDKnqxdlalvkAn1m5b0W/fLyfrN+bIqPK0Ak8owJ4 eQ6R+8OH5yX0cUFj2+Q8VLilquxrIiyYKu/4dnHoZp9pPXT2kSnEhyaUn+Tw5Q== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Frank Haverkamp , Arnd Bergmann , Greg Kroah-Hartman Subject: [PATCH v2 05/11] genwqe: reorder capability check last Date: Sun, 2 Mar 2025 17:06:41 +0100 Message-ID: <20250302160657.127253-4-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- drivers/misc/genwqe/card_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/genwqe/card_dev.c b/drivers/misc/genwqe/card_dev.c index 4441aca2280a..77b2d191d21c 100644 --- a/drivers/misc/genwqe/card_dev.c +++ b/drivers/misc/genwqe/card_dev.c @@ -461,7 +461,7 @@ static int genwqe_mmap(struct file *filp, struct vm_area_struct *vma) goto free_dma_map; } - if (capable(CAP_SYS_ADMIN) && (vsize > sizeof(dma_addr_t))) + if ((vsize > sizeof(dma_addr_t)) && capable(CAP_SYS_ADMIN)) *(dma_addr_t *)dma_map->k_vaddr = dma_map->dma_addr; pfn = virt_to_phys(dma_map->k_vaddr) >> PAGE_SHIFT; From patchwork Sun Mar 2 16:06:42 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997878 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 5371E1E9B20; Sun, 2 Mar 2025 16:07:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931631; cv=none; b=M2CUrG1lZ+dctFKufdCxjxFskf7nIT0SNdWYbrFTVNvGQx4RmHqlgg264e+2hYssLJDGBBXLbtYuZxNLh2xMdSIQhImpMpr1f/tVz7W6DtIBeynCNxDZ1uASYPD1dZzBB3ftmKFQIqmlDV2QOsKqhCop7YhEkH0EDu70nxNd7F4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931631; c=relaxed/simple; bh=b4zervl14GW1lM0RoQVhCTLqxK68z0fD6ACmcGqCLUo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iYq9hOdjuLGIAJdyOReS9s+qJXMLV0pmz+0xAlx4+XSzXIiBmTyKlHBkKxXaNqeTBN2n3WRqBbHJQKl715LSaqKhV8FIiM4idbkSz1hakz0t/rPTP3vgBN4VuDBcUrKGcvxEGqokAulu5d6kUHpGL58cT2OPOnMdnbRFkOK7fsA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=SJbl8DHf; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="SJbl8DHf" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931628; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lrrmxCSXObAFhEIo/8fh8weOhY7nqO46PR4GZl5VqBk=; b=SJbl8DHfCbWjEsjgne1Kob32i8p6jeDt6GHFv4OHAtoWeQ3lqXQcKH4uFnMbjiXjMxOD6a 0yRMpAHp77D88bW+DSL4gMGtBcz/cn0z41hBCSIhjBCucvOxUc1Ibv6JN4PdD4Dq6KUXPl ZaqJkLCDLg8IMc7i9s1tWJ3YLbESgH/3IhrQqjeQVb15+7Cxff/WR+OmoH+76vSvXTLDJy ShYO5VNs0yw2fJWUyo1hI+voMdz6a1l9KdGkua3ARXCyFgGYAy3FWIW2apEV5XIgWzPAPq VFeNDqXGoXU2MmvoP06ER9PS9efSClP7dAz0a9k4nAWEOazqkc6cMGnVZqroFA== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org Subject: [PATCH v2 06/11] ubifs: reorder capability check last Date: Sun, 2 Mar 2025 17:06:42 +0100 Message-ID: <20250302160657.127253-5-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn Acked-by: Richard Weinberger Reviewed-by: Zhihao Cheng --- v2: split into two patches for each subsystem --- fs/ubifs/budget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c index d76eb7b39f56..6137aeadec3f 100644 --- a/fs/ubifs/budget.c +++ b/fs/ubifs/budget.c @@ -256,8 +256,9 @@ long long ubifs_calc_available(const struct ubifs_info *c, int min_idx_lebs) */ static int can_use_rp(struct ubifs_info *c) { - if (uid_eq(current_fsuid(), c->rp_uid) || capable(CAP_SYS_RESOURCE) || - (!gid_eq(c->rp_gid, GLOBAL_ROOT_GID) && in_group_p(c->rp_gid))) + if (uid_eq(current_fsuid(), c->rp_uid) || + (!gid_eq(c->rp_gid, GLOBAL_ROOT_GID) && in_group_p(c->rp_gid)) || + capable(CAP_SYS_RESOURCE)) return 1; return 0; } From patchwork Sun Mar 2 16:06:43 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997879 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 EE0041EB5CB; Sun, 2 Mar 2025 16:07:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931634; cv=none; b=G2huzP06wyHtke+YS2KXTAZRSr+Md4HmyJDazz2HAnpc6WSJ44nLj2wraIR/8pr5ABfE+lxx7XbQejrx/lTGnCXyYXt5P+Ej+8wxYbm2S5aY6zhVHL4E5Ysa70trtwC8loYLJbgXX1SZwd9/RUy+x9ieIZKCs3qOdQIZ3gF8KL0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931634; c=relaxed/simple; bh=0EFiP6ygydcKWyW6csJHAZmx3Qp2y0CPOFwjWwSjus4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IZxztj8K6itAjEnAQQWLvhYNxg4kk/vECKfKwLR4zQqmNnIuNEZmqDS8Zn+pGrzIYF/HGDUe/Kmtv4VUal0e5Yzm7oKy0p7Zn/eNy4dtHfNCee6XVyzcbD3Rw5tQTHhEceJJt2cFPWy2W3O/RYuvVrSC/rP5GnIOXVcK7MPIz1Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=L00+6xuu; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="L00+6xuu" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931630; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m7tEjDSgKvohdvK6pTN+ndS8THOOnhPlPkLJOHpGmuo=; b=L00+6xuuwiWduCv+ixkmgNqzMue8FepzjU+fPTpLl3F5QZOO27bk7M9wmhhWU8jT4crfSL M/7o09GRptVOm+HsIO9YOzFhbaHCvz9w2ZOEuXxwGv+gKYE2NJQPPMme+A8tlGmNwEs9Hc zPxhTr1xrvSbV+1FwKr4ooR3KG+Nuqah7c8wXDMWW23rsD/wuGMhE+XSSuxU6acEaBKxjU SMoreM+GacqhtPwtqg8XONVAirj0PqdKl+b+IaRgbRc9E8o6K0amJ1WFuaGVHcfzBkbpnz CSZFhosDGBLKiF2l0uokkI6/gp4rmRVY4ARa7sYCKIATyzRBtNmg19WhoyltuQ== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Liviu Dudau , Boris Brezillon , Steven Price , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org Subject: [PATCH v2 07/11] drm/panthor: reorder capability check last Date: Sun, 2 Mar 2025 17:06:43 +0100 Message-ID: <20250302160657.127253-6-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn Reviewed-by: Liviu Dudau --- v2: split from previous patch with unrelated subsystem --- drivers/gpu/drm/panthor/panthor_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index 08136e790ca0..76a10121f8a8 100644 --- a/drivers/gpu/drm/panthor/panthor_drv.c +++ b/drivers/gpu/drm/panthor/panthor_drv.c @@ -791,7 +791,7 @@ static int group_priority_permit(struct drm_file *file, return 0; /* Higher priorities require CAP_SYS_NICE or DRM_MASTER */ - if (capable(CAP_SYS_NICE) || drm_is_current_master(file)) + if (drm_is_current_master(file) || capable(CAP_SYS_NICE)) return 0; return -EACCES; From patchwork Sun Mar 2 16:06:44 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997881 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 AEB8E1EB9F6; Sun, 2 Mar 2025 16:07:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931638; cv=none; b=cr9u2nylqGOOlxyWYCwRiYMYRNSSJj3T3H+Nt1Do8GhsJ/41ifHx10jZYRpW+GNPAY9GMFaunjt3pjT0lOF2iqL+Gl/TqvHrJ9Vr3/ViVJg7BUm4q2fdb/oSJTrWXy442pVyCQ2aGWx2SEnCCVQ4fke/HtvHcZaDNUWFzQy5Zlc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931638; c=relaxed/simple; bh=gFOJT0wB0FSlXbGcMSMgBV5jMo2IV+QAp/xG5QWZs4U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QbdbeIxogxkQXNurYv/GiDvzcGkoDWOX16Q1Ez2ehDEOx+9oioayRrrYyeoSOQOp+WnkzpEfN7YNqhiBWWT5ZNr/j2SPP6CDtNdFKioQKBH73QSjbnEGaP458Ye5xN9xRBERK22rgBWzLBrI+Bk4ELsOX4lVxydnQY8ur/JwXow= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=dUvVRk5r; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="dUvVRk5r" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931632; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ci2qYk+Y1xa6/y45CJ+sIl/Sp1TENvs4r3jA8ONoz3c=; b=dUvVRk5rsMES5GBkWhhKkXaw+xPN53mb+fYciIN3XGf5bDpEl7+9mczP3DBrL1InukvxKK b0dTreVkc3Zxdv3jDxO5zcTH1n9l8R9sY5BXlcHTtL8khofEs3ILoWQMspSNMue63EzBYU +YwZiQJDnQ+1PVyao3dSz3wGNpQEGWeTOgQcaAP1oVgJcWFaFgGeQO1jXp4uy79BtzcCuu 6U7B98CQ1jWs+w8FVp+HATHqVbw91duaAg8CJoUC8yHNZfQi5bJ30eFRU3jYSb299OwaC6 Um4+yVux8blZva5BIDm9YuDZQt9EsTVae9ZKAG2GSDJZptbEionJH8VsaJnOeg== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org Subject: [PATCH v2 08/11] ipv4: reorder capability check last Date: Sun, 2 Mar 2025 17:06:44 +0100 Message-ID: <20250302160657.127253-7-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn Reviewed-by: Eric Dumazet --- net/ipv4/tcp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 57df7c1d2faa..9828bc5712b7 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -3419,8 +3419,8 @@ EXPORT_SYMBOL(tcp_disconnect); static inline bool tcp_can_repair_sock(const struct sock *sk) { - return sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN) && - (sk->sk_state != TCP_LISTEN); + return (sk->sk_state != TCP_LISTEN) && + sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN); } static int tcp_repair_set_window(struct tcp_sock *tp, sockptr_t optbuf, int len) From patchwork Sun Mar 2 16:06:45 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997880 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 05AE41EB9EF; Sun, 2 Mar 2025 16:07:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931637; cv=none; b=KaXgUIPxQfASbcfyemA3BxwmtNrXi6NV1cLE3qM15jBCY6wL8V1ADOMcE6Av130tWxxdBpIEz9h0sp5fkzvy1mDGcNxKdJjyy39EwmyEvIhBHCxVR/zx/Pdi7BN0XYWFV0WQF5WonhQnaSdFbgcp5DxVIA7aIp9Vz+7xqYpKl8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931637; c=relaxed/simple; bh=MRV1BzXFzVKuXXCzfT8MZMYwjH+JUp8WlpwQIsq6O88=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lxkUli/Z6yaa0S36/EjBivt5qVvYP73bOPuDORUaNbXuAyOPdqycJboSxIHm8OwdxEYOmpxcbr6gejanJDX5MP6Dk8WcQ4ukaWmA/OYUmmwsLsNxEzZDqQP50UeMMjs4jgS7KrRZyTRg/RVaHj30UvaHDxwPAo08viMPRBgyjWw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=msLWUylx; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="msLWUylx" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931634; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KRfdkDgvTkBq7bn29Gpn8MyAqWDeCH+tjzpw5UYm82I=; b=msLWUylxKZrkZloeSFN5bZFcbLSbFE1cttvSkO/sbcFYzOZMJ7QrfX7q/KeJKDTCCqgTwE Cmy7gxyKITqqPUSpsCS7G1MqMRTPEE0rGESChTm4bdOm11qcFfU19VdeWkGdCDRk2erDxx kDdrSiGJC8bqVFfFWelDM4gaS0EX1FJAHjToIV4v7qro8N7Udd/eU2b50vvHw4+nCCyDVp iMV4JdyinVFOmyN1MzYoME93xKcoQ8EPz6PyS8U/d1Bw/PaS5g5Ib0iiqfD+QrZDeUyCFv aH0d4JvaWftIryzqqBPR8zUxtU31fm2LuQe5b2oX22cLwFz/FOLen82uN8NLOQ== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Christian Brauner , Chuck Lever , Jeff Layton , Amir Goldstein , Alexander Viro , Jan Kara , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org Subject: [PATCH v2 09/11] fs: reorder capability check last Date: Sun, 2 Mar 2025 17:06:45 +0100 Message-ID: <20250302160657.127253-8-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn Reviewed-by: Christian Brauner --- fs/fhandle.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 3e092ae6d142..5b77b38f0510 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -303,9 +303,9 @@ static inline int may_decode_fh(struct handle_to_path_ctx *ctx, if (ns_capable(root->mnt->mnt_sb->s_user_ns, CAP_SYS_ADMIN)) ctx->flags = HANDLE_CHECK_PERMS; else if (is_mounted(root->mnt) && + !has_locked_children(real_mount(root->mnt), root->dentry) && ns_capable(real_mount(root->mnt)->mnt_ns->user_ns, - CAP_SYS_ADMIN) && - !has_locked_children(real_mount(root->mnt), root->dentry)) + CAP_SYS_ADMIN)) ctx->flags = HANDLE_CHECK_PERMS | HANDLE_CHECK_SUBTREE; else return -EPERM; From patchwork Sun Mar 2 16:06:46 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997882 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 009DA1EBFED; Sun, 2 Mar 2025 16:07:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931639; cv=none; b=Ef3982hmblbtJyAH7H6ef/j9Y1+IBeVhSXBDxZKxCvvE8OD/PgjUrZ9OCSk2Dl0x4wUdUqZ/tEyq7mI/tiAdDAbRm+DjNMxZmy0LyDRoGP5qhzRck2Q7DP6EpjlfE2rNpHNsdWU3yQ2WB75xmNcMmTr8oNieJnc4dF4chhOY5tM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931639; c=relaxed/simple; bh=RN76k8ewK6+gsyTcan9ooTB7HAoL+bwmZL7k3n+IX8Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AEzCQdliDIj9ktUJ5HtRkLR3imIwOwW8sZMGdyUFq7M4pGesLvi894T95E8bveyEwhzWi2A4F1Ss8cRy6ZvUol2Sxt880K5a7i3sDu1/p19yd3Rv8h+M1RUwokRFAtYiIbU2Yz5GWfatK9ptCpR1o6M/qCbm8lZOAQS58wvbHD4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=k54U/7Dd; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="k54U/7Dd" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931636; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fpiJeKuvGtt7uxh2hFS+dsziMi5lwoHgf9YFZ4de7gM=; b=k54U/7DdT6xtoAVoeM2idgM1EIL6B5xU5Evn3d7IbnrfCB2uh2H/qmdz55n6qzYx70t3uH 0p35FZeateL7Ag1b3jOl59aFVU3uNUOoOaGtOoNKxNo3iH9LD7LNawzzrdlfxamMZoAHC1 T4vS4zw8LYD9l4XzCHBQ9dNgv8JAvXRo428TjONJUaI0xQTyFQMJX+VS52vdyUL23crlYb +J4Sv/UqlrVYkluFgPUsjHozs8BE3AiLiM8Q1M8DmCmIduSNhFqN/T0n9qRtUf54yqrNCd +sYwCjsV5cLzQ5txbqd95Gy8aMLJSbY4fHiroYyecsj9apwFsLeTUQqV7hOD+w== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Willem de Bruijn , Mina Almasry , Pavel Begunkov , Sebastian Andrzej Siewior , Christian Hopps , Alexander Lobakin , netdev@vger.kernel.org Subject: [PATCH v2 10/11] skbuff: reorder capability check last Date: Sun, 2 Mar 2025 17:06:46 +0100 Message-ID: <20250302160657.127253-9-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- net/core/skbuff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index b1c81687e9d8..7ed538e15b56 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1566,7 +1566,7 @@ int mm_account_pinned_pages(struct mmpin *mmp, size_t size) unsigned long max_pg, num_pg, new_pg, old_pg, rlim; struct user_struct *user; - if (capable(CAP_IPC_LOCK) || !size) + if (!size || capable(CAP_IPC_LOCK)) return 0; rlim = rlimit(RLIMIT_MEMLOCK); From patchwork Sun Mar 2 16:06:47 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_G=C3=B6ttsche?= X-Patchwork-Id: 13997883 Received: from server02.seltendoof.de (server02.seltendoof.de [168.119.48.163]) (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 3ED5D1EDA02; Sun, 2 Mar 2025 16:07:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.48.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931640; cv=none; b=B4FWpwuDliEFv6fqbWxKEZBWUoLpxJ59Ob/q3NRwH+hTLo5p0uqgpjo6p356x2DxKda+Nn5uS/HkrW+eGJlYWDGed8x9rzWOGSqiySgbFIp9Iu2UR89gr5ZFMgV6Q2tbyZtXfCjISQsIFEqKhOcY0FO+SrvJLa/9BKIk7VEXgX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740931640; c=relaxed/simple; bh=hG5wDTWcR8zF5/NiAfs9iFY426cOVlVEQeEXNvoP2m4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uFd2DFWuG6RyAGYp1Yffj3eBD1ItiNFGnlXjAKXX7TkrwxPOcVFO4nmFfnaE/Pvi7b4qz/afAX+uZDH3aWXMuOlEk08kaHBYQnOkwHvD15FmbBd/N/8Rly0SBtNEujKt5NlT+Gzph5yFSUh9x0ZjdTccyZbYigBodPupAwkMbEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de; spf=pass smtp.mailfrom=seltendoof.de; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b=MLKYd4Sd; arc=none smtp.client-ip=168.119.48.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seltendoof.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seltendoof.de header.i=@seltendoof.de header.b="MLKYd4Sd" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1740931637; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NF/YqI75d1x611JoM4l5Hi8OXTx5W/dSbiWY2k23YlM=; b=MLKYd4SdfO5qik2qg/ZM3lU4zBjr8IBNR7BtbJq+86SS9zjTtf4FQlORIua8KO1wZyFvaS mEbMF01enB6UzQO8S/FNHd2Kcfy+xmZtQKAFIyDoU+ldXKcFr8JU1N8LUxYu0DBVE+1xKe A3/oQwSmFVXrYKkVCcjlcepGhrBaSB2XQu2aifDAoB2KRvU7i3gp6SMLEU4sttW1Yk3cta OXyELxf5MK3Q9R7AVaF7wvbw9ZVjS7PUGAICEE/8oYh8XIJ/Cv8lRzk0EGb2Bgdt+puAZh f7qy1HJH/M8cSYLHHn1PqS52e3NMY+K0LccSETFRFHdYJ3e0Ibzv1tK2al0Byg== To: Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Jan Kara , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, cocci@inria.fr, Leon Romanovsky , Jason Gunthorpe , linux-rdma@vger.kernel.org Subject: [PATCH v2 11/11] infiniband: reorder capability check last Date: Sun, 2 Mar 2025 17:06:47 +0100 Message-ID: <20250302160657.127253-10-cgoettsche@seltendoof.de> In-Reply-To: <20250302160657.127253-1-cgoettsche@seltendoof.de> References: <20250302160657.127253-1-cgoettsche@seltendoof.de> Reply-To: cgzones@googlemail.com Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Christian Göttsche capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn --- drivers/infiniband/hw/mlx5/devx.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c index 4186884c66e1..39304cae5b10 100644 --- a/drivers/infiniband/hw/mlx5/devx.c +++ b/drivers/infiniband/hw/mlx5/devx.c @@ -136,12 +136,14 @@ int mlx5_ib_devx_create(struct mlx5_ib_dev *dev, bool is_user) return -EINVAL; uctx = MLX5_ADDR_OF(create_uctx_in, in, uctx); - if (is_user && capable(CAP_NET_RAW) && - (MLX5_CAP_GEN(dev->mdev, uctx_cap) & MLX5_UCTX_CAP_RAW_TX)) + if (is_user && + (MLX5_CAP_GEN(dev->mdev, uctx_cap) & MLX5_UCTX_CAP_RAW_TX) && + capable(CAP_NET_RAW)) cap |= MLX5_UCTX_CAP_RAW_TX; - if (is_user && capable(CAP_SYS_RAWIO) && + if (is_user && (MLX5_CAP_GEN(dev->mdev, uctx_cap) & - MLX5_UCTX_CAP_INTERNAL_DEV_RES)) + MLX5_UCTX_CAP_INTERNAL_DEV_RES) && + capable(CAP_SYS_RAWIO)) cap |= MLX5_UCTX_CAP_INTERNAL_DEV_RES; MLX5_SET(create_uctx_in, in, opcode, MLX5_CMD_OP_CREATE_UCTX);