From patchwork Mon Nov 25 10:40:04 2024 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: 13884800 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 8E9DF1AB501; Mon, 25 Nov 2024 10:40:40 +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=1732531242; cv=none; b=UXkNvetqqVNon92V5oOEegDzy/h2OPTvoBceg8rYs8HQezown9JqWK2/8l95dRCuwrpLwMXDJmjxgImeDVxnkSMtXLEC3OjyhAstfRVnT9Yn2dSFtMLovv1zt6Vfao2nr8hk3VMxYvroKoF6Yr8t0G6mFcCHqv5oy3DsNORceqw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531242; c=relaxed/simple; bh=PSaQOMGKr/Ve7TwzTNQdr5+VuDZ1b8z2M3mr2p+Da48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cdF0w3KwqYHlUYh6ZcK5yD2Tiq/YZh6rh07JW338ABTxn8qJ4KhhDySzsQWTAgRaCPIft5BzuxzC/aPsd2Ggjlq1EVw3VDDObqiy1FToh2PBlDqzRLsvACnrfFtmiY1EFQxTDztX/QVEevmpy9NNl9/ofVPLcqQM2h+SeEMFHbM= 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=jSKVqFEx; 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="jSKVqFEx" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531238; 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=5x0yPCIryoiXTXe24z13INkplAFzoVmn1x49aPuCCtY=; b=jSKVqFExQSaxinJXOrSxNiS3t8Eipge1vhRHBNJjhjCz4n+7KScfgPxBuo3b46kSVLhJ2j 0UXhFTBuKx0joSbRghed5bds0gNwtkpqrBXIrEoXXXFKSX8qE9F0glBVwfeSpHJWMuHfz2 nVV0HJum8Ip7bUeU4cuswj8g9PjYLTmNs5vzPTZx7cQt/KD5M6+XKYaJ51YvSi/48XcQ/0 7c37i7/iZ5dQQDciVeEFDG76UYubJI3Gk7iK28SGmDxf2ZG2FeVzk1vdHvZ91lOAfTaaut JWZBvLX+qbBYQn1/zRqcUXDbxu5PwSHYCEUrJraSUnNW55PMAPFq39B1zB9tFw== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, cocci@inria.fr Subject: [PATCH 01/11] coccinelle: Add script to reorder capable() calls Date: Mon, 25 Nov 2024 11:40:04 +0100 Message-ID: <20241125104011.36552-11-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 e7f017097701..ab5ea47b61e2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5106,6 +5106,7 @@ S: Supported F: include/linux/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 Mon Nov 25 10:39:54 2024 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: 13884790 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 3A9FB192D70; Mon, 25 Nov 2024 10:40:30 +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=1732531234; cv=none; b=I7h1Hs2DAKJAfbJ2MUd2aqPl6bvM8iXjH3oJ2ry/tX3Lw3AtFP/Auvoq0m+2Fu7NW+oOqmNL2hhRIJMte9tohN0ifjg2ZqRO6V+86uncEW10nkhp2cCrTE6H6o7f7NYVq5Y/qjcAFRUcCV4iw96CF+FhBbFWPf8+WqHZYSSf65I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531234; c=relaxed/simple; bh=/RTyild0b7BT+76FJnjYMZVk+Wy7NGYbYU493r0v9V0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Eoo6EvbHoZTW5hiYhdp3fTNN5oxajpp0CRRUl77T3j23x5+8lqG8mvda5PvndlhDovwFOVrLekethEuQfoe6oT86fqaQBBSqg3/BRRg+I70QdYY6uiGdVvqe6w6trTOEdYTCmUM2TdxLGEZqkjaNG+mhPtQZq8J7Yhwt81D7spA= 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=jFlHUnSJ; 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="jFlHUnSJ" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531222; 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=17lhHTnnZGmrh/UycwQ7pmOcwP/SDxseygpcnk52sbc=; b=jFlHUnSJvVahXsR69S9gj5XhwOZOsx5mApFRT8497wpNJyGwwA7cfg7pEHClwY3EqMnwJS 16s13rukrF0jxcnU4oJZse0adk+QnpoVnIrLGjWT3Z3v1hqD0/rz3cKNL4icom2QnisO+O 52mTcwDrpYGSSIO5tMsUSRk249MQUpqXOxopVq4MvMOHI2hNIrgmXrIQ4lMEIPLvaLvo1o eil+6vDCkSBuqJtZei1xOBeQ6SmFf5x8awUZo6AhLqGdzAdbtqT6DNM4/LYTdsN+RzomRg Pa94yEk0S+pz6JHp2rzZRP/L46XO6/mQecqyF7JlaS9Ty2QdWS9rygJkL3FXeA== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Jan Kara , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, cocci@inria.fr Subject: [PATCH 02/11] quota: reorder capability check last Date: Mon, 25 Nov 2024 11:39:54 +0100 Message-ID: <20241125104011.36552-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 --- 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 3dd8d6f27725..a2dddffeaac5 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -1281,9 +1281,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 Mon Nov 25 10:39:55 2024 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: 13884791 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 C3740192D7E; Mon, 25 Nov 2024 10:40:31 +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=1732531235; cv=none; b=i4W0ljPdcK3h+2flWjqH4Z2WDPJ4s53h/xdMm5bF3NZ+YegialndgN3nMC3FBEsd9OVcHO47Dcj+JSlRmltMwm1OPfo+cnZgGZw8WeOwuEZDqAIulGsq3TR3d/BrH2AalbnBxB8zY06AD76LerRNhhRiGBUu9hx8f7D6fkkG72E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531235; c=relaxed/simple; bh=1o2+SCKbPMlZSfhshov97BHiZ6npLENrivJUl/obBl0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Qoj4a5zs1bFXQZyexigvl1LUhMGqELN1rtey/zVovcns7tsMbMzKnQMX4MHaQfhYwCeTjyTiE9Srmn0hCeO65o2tk2MLA0ERta3t4ivK8Vi08S/He9pqQFtsbgp2s9FLIS+LO6AZNTEFIQibf/Wk+lk4l9lxXCs6lHuiaQqjpAg= 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=nqGJcLfQ; 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="nqGJcLfQ" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531224; 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=g0u/9xnJFmCzCIsRXywH2TwoCekIvWc3+cszQ3gofsI=; b=nqGJcLfQpuCPVU4svGCFemBiN+Nqp+1R16Nvd1Z8RvKusipz8MFxJLNdU2uhjFvntoOYSb Xj1L3BtASdJeevaSB18S7Dl4G9iVy2NeKuB5bVvlEQ/00Zw4mWcB4rc9Y8T8msyZ1lYG1X 9EFJuwkmLAYq+yC2ipfy3AxGyZxlF/Jc9QDPrMphpZ2z7VT/m3D7jllOSk539ISoY/tFbc kSn7Zr8qrh9mhI/pb9WE7RVtWlm2DpAmQRLqFEX0I9t3ojiACy+XuvtER8YjGVp+0wWSGE NlMPqw/DtS7g8Ao5UdD3jNlwW46B8Yn6PoWxwEILbI/QoEnLV0D9q/lx/AKSKA== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , "Theodore Ts'o" , Andreas Dilger , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cocci@inria.fr Subject: [PATCH 03/11] ext4: reorder capability check last Date: Mon, 25 Nov 2024 11:39:55 +0100 Message-ID: <20241125104011.36552-2-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 Mon Nov 25 10:39:56 2024 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: 13884793 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 67B8B1426C; Mon, 25 Nov 2024 10:40:33 +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=1732531236; cv=none; b=EWuKFtJbUE2AdFPp8xBuvnkcewWG4rBIiciA+U9oBsqHt95nBo3hhO6W1+7IslQFtjqyFLURr4BNl9FV3/yD4aukBPTb9C9ohAvEieHPN2Rwvwjk5KTZ6duyLoZhH300xFS1kQnVYxba8piciX19lQj9Bd74prmbxMrQlrDykZQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531236; c=relaxed/simple; bh=RiX1qAPwXOtMydW3Bf48L9hzhNoJhOnr+55MkoLjnyI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WEwHpd2b7xsN4Fgak6CTMmG++kOi5KWJ05g4X5RrR6O5StsoQtgUgso74HRldCr2hb/Dsue/GwgkWSyOoB477BQ0X89IDHT6SzYJIUwUcMbiHVN8J0tNcTcvJypfQYIDOCgI4pxlkCNTKIWAB0A8zWKT3XNXg1xPiBS4+S755t4= 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=Mdb4xOeL; 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="Mdb4xOeL" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531225; 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=uXJbjp9TEMr3wvQ+2vZpGMNVJ7tkSZTdw7fouyXGnz0=; b=Mdb4xOeLmRxHgooUx3JOijX3+LMSlj4GRxvTHEPWd1og60SnG27YZkYD2Ceyjx+7B333QM ZyLgYWtMHFmpAS4jQ0VS7zdfJq9cQ9qMI1VXAh2OJqLOjuiladwhEQxhs5QkMpM4d+88/j YY61kw6/zF9K2N5hNSbT40SYIj6CvC8CdzV+bU9xHoZrZXIDj3azO4Pssrl2ovpBnSmIzD Mv0etwsaWtD04zX2lsGfDFSxo61zYM7APvut1Mn8G6dTOzCPF4BW7lPtuQElc1iacTmQXf 8qW38Pn8ScwYATLiIG45X5y8yS2CZ7A99XQg1RtL/r9qa9EeW8r4/TzXlS2Ylw== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Muchun Song , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cocci@inria.fr Subject: [PATCH 04/11] hugetlbfs: reorder capability check last Date: Mon, 25 Nov 2024 11:39:56 +0100 Message-ID: <20241125104011.36552-3-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 a4441fb77f7c..e4f6790c1638 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1508,7 +1508,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 Mon Nov 25 10:39:57 2024 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: 13884794 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 B22791925A6; Mon, 25 Nov 2024 10:40:34 +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=1732531238; cv=none; b=IZltobQdi+K5XmRfwLxjLYcQhPFxZy2nMzwVYnD9BBNalJrEiEirfU5mXMUeekvwBRx40a/KR+M0SuXEnw8IZ2XDHouhz2RWLpZNAUP4jV148blNxC+MdBZUbdTQILTbivvMAIOHsCPI7Ag1tgXpCWkml8TOoz9DdRP9F7BhTQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531238; c=relaxed/simple; bh=OINYhmpNgcEI4tTl8Cjxh0NZwDWWt5w395EWwdrZTOQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FBQSNiIa+pXj4xkjAcgYnHw1lIsHrmSHgg6sw1s7OSJGiwlkV/FSVVKwuqkppRTVrwVlArjuYaFgmLiN6/XC4ilTg2LCq8CtpnWwioI79zMcBNbkMaEWKN3ncCqcL2E2ZBOvcnaXb/xsaooKuPnl1rPkYBzqqe9uW57dOvlECg0= 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=fj/rRme9; 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="fj/rRme9" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531226; 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=P6AGqeaWbUDe9y5vDnfY9zmRKUFqqfOHVoZc9OQ1JdE=; b=fj/rRme9yehwZA25c2Ni1/9tPmwADULk1KpFn/cVxyAjjBhxyj8Rg7aA5iUrANhXFj3LDF EVEGpnqH2qxuU7xy7zbZVAr4PN6VXR1u6SaguSc7GBpAUwBFP2HQJcV/7rETu2atweRoUA DK3HuU8potvt0ji3IF7E3NaCAPi/OzmAMILLwPVEudy8K/V1Sdv63rqOny0qQy7l6LvQi7 Qnx0BqyipTaX8aKvcgEzC2iX2EuYf59bvAQ8Qid3xQZb/Mswa40vldOlKBAAKO8BzLXU81 uOeCjHBIVLuJs5xjOP6IrtRBAxUkLS0+WGDcxbdL3NWIKBOcibJLOqsDLIBdFg== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Frank Haverkamp , Arnd Bergmann , Greg Kroah-Hartman , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, cocci@inria.fr Subject: [PATCH 05/11] genwqe: reorder capability check last Date: Mon, 25 Nov 2024 11:39:57 +0100 Message-ID: <20241125104011.36552-4-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 Mon Nov 25 10:39:58 2024 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: 13884792 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 DABDD193064; Mon, 25 Nov 2024 10:40:32 +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=1732531235; cv=none; b=b6Dlejcz4+ob6Bd7VijiV4UqjR3JWR81dvN+oTlQ4o4mWtA8Ik5hRYAmX+keFmutjLGUZHytYtwtMkf/zOkerkc0ce1jF6ohmUJ5FQSvuzfyOGg3uONBJCb4NZYi4K/baQpQ8ZCUIaBWCQgqbsAC/hV9rzVcsrXVq0p1Ygi9TP4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531235; c=relaxed/simple; bh=VhnL2wmSb+pfgIHkp6bvcyX/tRAnbRI3P76lLhLZZrc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JiNoiifgIoHbhXMbwzVc84NbL/ueGpyiXMo0OIroByecsPjdnrm5vd5jcxXe8dyjPvMvVEZ2VbOC88jDu9NgKO1OwmJFlSffhViatZdzg0GPXA0XeGKjP4NPyiUeBL36UoyHLfxV1JTBc2DU3bBJ9pd+li0DJOi6wUkFqa6RfM4= 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=renzaNjY; 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="renzaNjY" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531230; 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=BnJPwZBINKy4LES6pr7BNEYT4c7M8sYvf1DiqcmfvZQ=; b=renzaNjYJ9YJyG9gUtmjWqJwQ0VY7TQPB8AIE5W2eHdeqh2KtO/X4RlDCy1my/SVpQmQbZ wjNEjBd+3Nx5SYzGSi/4OwNEhlCfesxm4VNww0jT0OEYCfKsxUBHnyqFZjs4qmm0yXdPXf JQVxhmVSoR7oSv45zcTLYW4BjQnZhX+TQ9oYJfvSmhOwIXh5wbGCNS9yLVPQ//3K2TAHgl Eb4e91BrZZEw09F7m/z/76uD9fpDEgjnOst+2rcsjNChNW2KdjtqLgROIapy8OMfgZI/BW MreOsqodNcQhtkdGSCQM3CtyEM177zZSZrrnzTyeG6viMRNF26psOPQLgVZyPg== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Boris Brezillon , Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Richard Weinberger , Zhihao Cheng , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mtd@lists.infradead.org, cocci@inria.fr Subject: [PATCH 06/11] ubifs: reorder capability check last Date: Mon, 25 Nov 2024 11:39:58 +0100 Message-ID: <20241125104011.36552-5-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 Acked-by: Richard Weinberger --- drivers/gpu/drm/panthor/panthor_drv.c | 2 +- fs/ubifs/budget.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index ac7e53f6e3f0..2de0c3627fbf 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; 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 Mon Nov 25 10:39:59 2024 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: 13884795 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 1F704194C6E; Mon, 25 Nov 2024 10:40:35 +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=1732531238; cv=none; b=CHOUp58Z6SL6sRWBkBID6H8Rp//x2DBVWD8Ef2wQ3y7WL0h/C7UUcQgXRqhtYDwiX6K+wHt2T1XZSPAzrDGD2bAqTtiZW6+2kvBp71xUkkHS8gKBt59AQQeGcLxBfIZnuLDTXKLI0PkTo+7NVelloDJt7ROP+k3iq4CAc6TOmRA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531238; c=relaxed/simple; bh=cO1yPL6/mL7nkUA25VaU+cKW9bIPnwazWGqCpFKgihI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZjuYjhxY4XmeTo8jcP2AgS5YuxNxHOWJ+Dug0xqI3Urd1wxQY5d8dWh+azmJG5M7/uobr0H2wHTY4syDGArp9pQyqTP7oYxbuaob93cgx5oKDza3fFHG66v3lGotOX3BbNt5HZ48R48kKSqP6VhCt1TFk5KGx4xSOQCGRlaoBwY= 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=E5uuCsWL; 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="E5uuCsWL" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531232; 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=7wVOSUhPMHDDdyWhZb1LxKVvZ0vAeRZe7OwxlJZ3FIg=; b=E5uuCsWLjd+f5UuRf0P4XipqTBXRFNmMzjfboQYwQD7a/vLFsAnUw1bZ56W3QjCp1wdjVM OQqtKYGM/yAjFf3k+3k1jtPdsniFUNb11UryVGQwNUTop3xUf7ZVrtrQIjGWtilvfkdwKr f5CG7nKKLyLEXJFWK+BEEtF1j1ADNYhVn9diBKye0NPtrUUqKFn0jTJ5XhnaMFybt60XFV uhN5+nVRzW98zFouj+AP1ej6JEOdLWJAVW5VkO4tgX3YPw80iAP6cfcRI6i4Iann0ici2p 95U/wJpEbE+4mWtxePvaBHXM6KM6ysgwRRr0AE5h1TyAgH1Xmd3ufqAcedwbtQ== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Eric Dumazet , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, cocci@inria.fr Subject: [PATCH 07/11] ipv4: reorder capability check last Date: Mon, 25 Nov 2024 11:39:59 +0100 Message-ID: <20241125104011.36552-6-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 0d704bda6c41..bd3d7a3d6655 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -3406,8 +3406,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 Mon Nov 25 10:40:00 2024 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: 13884796 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 1D654194AEE; Mon, 25 Nov 2024 10:40:35 +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=1732531238; cv=none; b=pUBR5sxmDjKMewZKTmdhGw2lr6DghJ2bQUTkKVp/vrrVNr+dn1ocThhA4S5BTvoK4SeV/g0MZkN7at5f7nL/ZO3gSOG2hnSRF3FNO1bMC02DxYl9sk9XxH/Guphd0wZLk7cIVlopU9Y9Jhv5AAIXjkfbhqfQ4nxbQE4vv45hzk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531238; c=relaxed/simple; bh=sqRRylGkLtbdHiY0aJnVCbtjNbB4VGS+linaOHS6NsY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Jf/HXENEzliS5uJPlhsNyJIJy6mT5G/B2F9FhBLe5inYRb7bnh+Jt62DbFhg1UK+0J0loEs/YMx+B+cr8aH3wNJPzvhy24hjo5fHS/s3KWeMG5yJhvHscuNruqcwH/9uaGPfKD3ed9Gzec7aoK49lbjSaV6mNzjM10VAVaSZISU= 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=htLbeYks; 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="htLbeYks" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531232; 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=wEUm66qIu8PkMwOxCNnnSHqwyJubiCsERAs4lb+4vxc=; b=htLbeYksaORg5/HvEg6PKAtZC4kv17t058Wj3CTukaT/twqcgszc31G/pliYnDXAeXwBbx QMLvNRwy/9JY/gwAElTZUIR+VhYroro5VjcvBj36kROIgytwGOorYZM1uE3ah7VuglSwNJ AJxkQfGe5n5pbNgcZ1Rwi9TZs8GGnAWKUcc1cdRJgOLc8JE647oNbHFT07b/NW6yQe/mw8 9LPEjY1zZnx1vLvmbV8hw3+OasVI71Nk4ieD3f9NOoxnejq/Anz920QM/DOTM6uO7hcHXU 5BCkR9dAKb3kUbIeYS+K2wGlLZ4Z+FtponRFMBmBu3IkMFi7cKP95/dBb8x2Cw== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Andreas Gruenbacher , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, gfs2@lists.linux.dev, cocci@inria.fr Subject: [PATCH 08/11] gfs2: reorder capability check last Date: Mon, 25 Nov 2024 11:40:00 +0100 Message-ID: <20241125104011.36552-7-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- fs/gfs2/quota.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/gfs2/quota.h b/fs/gfs2/quota.h index f462d9cb3087..988f38dc5b2c 100644 --- a/fs/gfs2/quota.h +++ b/fs/gfs2/quota.h @@ -44,8 +44,8 @@ static inline int gfs2_quota_lock_check(struct gfs2_inode *ip, int ret; ap->allowed = UINT_MAX; /* Assume we are permitted a whole lot */ - if (capable(CAP_SYS_RESOURCE) || - sdp->sd_args.ar_quota == GFS2_QUOTA_OFF) + if (sdp->sd_args.ar_quota == GFS2_QUOTA_OFF || + capable(CAP_SYS_RESOURCE)) return 0; ret = gfs2_quota_lock(ip, NO_UID_QUOTA_CHANGE, NO_GID_QUOTA_CHANGE); if (ret) From patchwork Mon Nov 25 10:40:01 2024 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: 13884797 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 225CC193070; Mon, 25 Nov 2024 10:40:37 +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=1732531239; cv=none; b=lgKFQd3fQkMrIbSftYXbDAhpveMrL4yfiiCxzcrE6l0eFH9QUT95IPaHlbkrs8RND9/RbaSpY59yUPaCXG2/2tsLYEl4otVSQtiYshtM6VPb4ClXLihnkL8IeEdNmVpvg2P3/zO/6vp4H2+sudDG8NE/in/9gZuJKv7w4CcPXJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531239; c=relaxed/simple; bh=iQFabzcbeyd0VMqCL1uH7Fo+292SfpJATJ4pnluwUxE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Lz+PXjHnGcK+Rm5P+ugxqgCq2LdBXzZ6QRzubhw0PKu11sq23w5EtQ7LNqkPFGnMsRNaEvu0gdGq2gGkJfzmK5he9fAHa5982bdyLygmpUmLh7hENb6jklxUaFo7h5nrgLJEgnUbQE+MlEDvWM1O1jjAJ4xxbBjauzjyW8KHa+g= 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=hlpyVRYU; 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="hlpyVRYU" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531234; 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=z8toJKTqYgiOm8yX0/nayZUss8l7ma5sqSjl7KCBpF0=; b=hlpyVRYUw1z9xdZYuJDetCTFRs3+Z1lxqLniLK0tn8ZkmcWiAL0wZ78aQGq5CBamzi3BHV 9ieNcRpM7AGfB0BdD6l6XEGEzBKC9k8riy5y0h8JJXkaR+hA4W0RSz2SHOGCNm/utmsRAu 6scALFYJ6L6f4jz72hqrt5zCGRec5vFh8cJ8r+g/FidQPHC401sojwGuGwasJDZtsSuTG+ MFk4OzmeTYuB9D47W/amQTcxAHVR44Kd0A40nLT+O6oXPtDHrzLhNB9/rGRLHRQDFjf6nC uDUoXOqRx5fDWxJ10epkJwqkfBoBKMtSxMC4LcDFdEjqZI1nPZhmdSi/iwslTA== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Chuck Lever , Jeff Layton , Amir Goldstein , Alexander Viro , Christian Brauner , Jan Kara , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, cocci@inria.fr Subject: [PATCH 09/11] fs: reorder capability check last Date: Mon, 25 Nov 2024 11:40:01 +0100 Message-ID: <20241125104011.36552-8-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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: Christian Brauner --- fs/fhandle.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 5f801139358e..01b3e14e07de 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -265,9 +265,9 @@ static inline bool 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 false; From patchwork Mon Nov 25 10:40:02 2024 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: 13884798 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 839D8199924; Mon, 25 Nov 2024 10:40:38 +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=1732531240; cv=none; b=sECDE6XqApn9pQ89XlA/Di9UEtmFmDpGfdTykrUQ2jV5EJuTRotfwUvrmTW3PCnPiN8g/rTrlzfs85qub+0skcXDQ2xv0nDrmGpftt5ovdZP1WfOvM0QWTO8pWt5CKQMqESInTXlxHV6jscmmUTazL1emgd1dz2w5im+eUybyaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531240; c=relaxed/simple; bh=5zl918IEUyEEK6Zj6zbtZJmQTRCcBiXNutEld1pO/Ks=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UnsczJ3xfz+0i9zBBRgx6mLWFkJ2+Pk0DJAjywp8Ysy92JYKuk/17vp4Rc5V/4mqdJf8r86C/BTK94w4ioZavcUYLNB0Vbrq6jASp6GnfDaN+PmyszSp4mr/WUrFtppRZULUtn/mDIh1djhAECcjBBSk140FtVxv9Te4TJipC5o= 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=He/Nsu8T; 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="He/Nsu8T" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531236; 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=e3xkA6/OPtNWl6A170imeRaHJSFeFAlcMrS6betDjBY=; b=He/Nsu8T8nvfNlUyWxosD+aqdOqwmX/wEHaa2TjwySQRhsy3y5mTIIxk/xGqu/tcDJ5953 ZnRNBzqyhJWSs4bdvRWugPMdaEsZwP1EY0ud9vuXGWC4i3ViL8z0nnFQIVAsnam3OKt7my K2Ca6NHqvTfAEibYKAzLnT1cErwF54vzr0x0gtB5XB/U8Jumi5mAICsd54kb+UqDr39vt6 jctvGmD/eh545sdjY605727XRkT0xXG6+ZLYPvzo7Bw//DkeQH4/XwiZL3HYSTqumPksvy biWPeTD9ZM37zKthExv/H7ZnuC3e8ZPnbE/4hQKbh6oXoC0j3uLMOb2YBU12kA== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Serge Hallyn , Julia Lawall , Nicolas Palix , Mina Almasry , Willem de Bruijn , Pavel Begunkov , Lorenzo Bianconi , Sebastian Andrzej Siewior , Liang Chen , Alexander Lobakin , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, cocci@inria.fr Subject: [PATCH 10/11] skbuff: reorder capability check last Date: Mon, 25 Nov 2024 11:40:02 +0100 Message-ID: <20241125104011.36552-9-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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 6841e61a6bd0..8bf622744862 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1656,7 +1656,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 Mon Nov 25 10:40:03 2024 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: 13884799 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 8C8791A08A6; Mon, 25 Nov 2024 10:40:39 +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=1732531241; cv=none; b=AZlbwO5B7gGR2hr8/rHUMXq8yTiBwGz0+GTV5GVTY6Yuw2agx09PJz0np7grNdmL8I9/Gx8iibF9aLAF9IPsuRXd287VwmxPjyaA58L/4VqTA6PD18Am4qFw+qFYjLAuRbY/2AB2SeGgpKTmHpwqUNkd0W1ziSxnuhJwO96sjXw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732531241; c=relaxed/simple; bh=lloAGaLbURbVlon1dVtedwbqFYbXXpREa5EYQ+0jSvc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=J1/tDY84VVkOSC68QZ5mBu7QiZwx3BngMNLtkS5BuKry/o+ASwqRBoVk0ghq09xXckUxNqgV/ZI8IYZyhT/3Lzp6kl+AmZ4ZF7/q13x8KKnosr6SCragXvvoM6xdW2nwUSsaHlpJM+eQzOnWq0pNmqwhH/kTfQeKtehxYWVqvFw= 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=egFZ8oIa; 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="egFZ8oIa" From: =?utf-8?q?Christian_G=C3=B6ttsche?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seltendoof.de; s=2023072701; t=1732531237; 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=jlzbf+EP4WQ9ERhB8MeGSUxEvK9pVGrKH+pSzOMuEbY=; b=egFZ8oIa6Adyyq1lI/k2/7m4vxLRXLRn+Wt3Rqrnhzb3SfQ5501wiHrxZ5Hh82c9pnpMXM tYFM+X7VOO2MvY1lLyNSYdDsqdtL+pJRt3Q8+mM/LBcLLRFnb7XdJ1KQa5kGg/oCpQO9di bCgKaiQoeHAmqvvLNsihH1RYfcsOPEbEktZ8DrpivnKmA7oW295+etWpuflxh+/+m2mC8h JcHrixMYoiM89hrRnhz70aBFe5JJjrUZLCIRNJ5f+wt+8IJKX2gBONy56XdMKZzRYkhxLx sRNOVGL1GBxGIPYLf8SztrzZNZb5E37pWOmFQDg7gpMMuxzx91L1/e8x2hR+ug== To: linux-security-module@vger.kernel.org Cc: =?utf-8?q?Christian_G=C3=B6ttsche?= , Leon Romanovsky , Jason Gunthorpe , Serge Hallyn , Julia Lawall , Nicolas Palix , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, cocci@inria.fr Subject: [PATCH 11/11] infiniband: reorder capability check last Date: Mon, 25 Nov 2024 11:40:03 +0100 Message-ID: <20241125104011.36552-10-cgoettsche@seltendoof.de> In-Reply-To: <20241125104011.36552-1-cgoettsche@seltendoof.de> References: <20241125104011.36552-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 --- 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);