From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34F3EC54E71 for ; Fri, 22 Mar 2024 16:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D09C6B0087; Fri, 22 Mar 2024 12:28:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 958DA6B008C; Fri, 22 Mar 2024 12:28:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7858B6B009A; Fri, 22 Mar 2024 12:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CF8E16B0087 for ; Fri, 22 Mar 2024 12:28:28 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 740B6807C9 for ; Fri, 22 Mar 2024 16:28:28 +0000 (UTC) X-FDA: 81925207896.06.D5845D1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP id E38C6140012 for ; Fri, 22 Mar 2024 16:28:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of leo.yan@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=leo.yan@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711124906; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=9vYNNsWu2J7ucpvtRYDpW+Tb98CHzZkSy4Ql6GR3hhI=; b=1xERgwKEX7vTDiYQapr/iBCF3a4bHw+PJnbeYTTOrD/K+5/YoukdN7sNknP1qUtM5JN40g hbYysqIWFGEsZC4Zo9UHgTTL1NxJhP2X17ly0JWkwk1m6kdTTAfSOZgNmitbS8wqBk5xk6 bZhAmidUl2F1/ur283CczFPg4P4UHAw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of leo.yan@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=leo.yan@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711124906; a=rsa-sha256; cv=none; b=NBtvlDqJxFxcUpO1/6GvWBtbdMipGmULDJ8x6Jre9wcQQJ68xu95wSxgNw8yVuRUnH96XI +H5jUL0PeXJIjDo6n13t0KWfpQCmDBpOww4cMJv+jWuyjWRHAVIp/Q3G1DXf16ITDq8OFj P/a9RrSL2l1bV0nRvFqryqMT9g+TRtg= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0DC7EFEC; Fri, 22 Mar 2024 09:28:56 -0700 (PDT) Received: from PF4Q20KV.arm.com (PF4Q20KV.arm.com [10.1.26.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A2D2B3F762; Fri, 22 Mar 2024 09:28:19 -0700 (PDT) From: Leo Yan To: Alexander Viro , Christian Brauner , Jan Kara , Eric Biederman , Kees Cook , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers Cc: Leo Yan , Al Grant , James Clark , Mark Rutland Subject: [PATCH] exec: Don't disable perf events for setuid root executables Date: Fri, 22 Mar 2024 16:27:59 +0000 Message-Id: <20240322162759.714141-1-leo.yan@arm.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: kc9wr1dh54wdfe6f9y7uwno1p9d1twhq X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E38C6140012 X-HE-Tag: 1711124905-39020 X-HE-Meta: U2FsdGVkX18K5xz8IxIOvTFei2MkIlPRLAjaAxteafjz4KMOzRNTOCIQpVPF852vUPkG1Gc3o/gvlIuBcCMbgBVKZsoL6/UGiS2y+GgH7vksEiREyvzcHQRygDzWBX3Loy+c/WhGD0w3dOHfanJucHl6jLb0FytmJ/Ra2I8foUogGV/ke8zeNiknMeoA+xGsQaEyu2i0SBpPZwMhFEicmgp8J0igFMv5qwCMx8VPrtFhk7WK3IQm+EmPYo46Xp6rHByUkEqlTVCFmD+RpGxYnt6WRT1+yUDOH+2JbdEmp5pURuvg0sAaGG1/d6F6D9dhw7ut08IURwegjFHSpqCblw8OPAbTCHYAAishLCbqOp/BYTWJXbjTx++FbMtIHT2v7WNDYLoCayZA7bwB7oCyTMSRQgcCNhderKm9qoifoWGXfK2hbxIKr4igiL7dbmGaIwUIH7A2g+mfA9L4yqNnqml/j5xx5nRIzKHtiy/UQj2VuxJZNqy00iQ9XBW1YXfT7MrEWVIjRYNDs2ktujjLkEwVEBSHOJLteXJQMgLAqjLast7jNiUFlUlySN2jiemI/pMYjCp1LahZ54VzV6fHmIDcFibE2mrU5G2j6D9jPx+KsLkL8C+Kp+d0JP2ZtZbLvDoC7/1qFhWVPTfaPgTNprQ8V9pg8jt1Neuvl1ujEe9rXjETHel6CKyB5h0n1Jq5kxTVLFFK9IW0oSgpNub5ELO++qzjzuxuqT6zPvctZbA6N2nFRKOGhS+NLszAide/RbBzThnVY4L9SDBC5Ce+ikQsF68DsITiDAaoCjWPGAsD+g6sfd0486PGHJLa8ADSeAfgK00d5xMZR2CIFTboWJgWRSA+AYAvPD+c5d5dA1BK4MfLg56vi2qloQgarpPWSckbLduOohIqPg+hsPIFCzMP834+aLCQ+jnjC4TDvLzl+byOpM/G5Qp+T8e93v1q6bxMKDoSjAV4xboZxRI 3tzvj3nC z+E63vpj/7wdWc039WT8y/RGUtiJZVSHolnSE4D4WhgNK0/P9pupkqQCLWY3Xrfps9toh03+idb5an3yQfnoDLf8BS2Fx6Qm/Otz+JaHKE1d0AaG6oN+V7kOTlO4ZvwoTf6e/oBJrHkGaY18U8L3fGZ6mfJNkBjIc68Rbcwc55q/Vn8/tXVN7Y6Q0GOhSaFr8GxZ+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Al Grant reported that the 'perf record' command terminates abnormally after setting the setuid bit for the executable. To reproduce this issue, an additional condition is the binary file is owned by the root user but is running under a non-privileged user. The logs below provide details: $ sudo chmod u+s perf $ ls -l perf -rwsr-xr-x 1 root root 13147600 Mar 17 14:56 perf $ ./perf record -e cycles -- uname [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.003 MB perf.data (7 samples) ] Terminated Comparatively, the same command can succeed if the setuid bit is cleared for the perf executable: $ sudo chmod u-s perf $ ls -l perf -rwxr-xr-x 1 root root 13147600 Mar 17 14:56 perf $ ./perf record -e cycles -- uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.003 MB perf.data (13 samples) ] After setting the setuid bit, the problem arises when begin_new_exec() disables the perf events upon detecting that a regular user is executing a setuid binary, which notifies the perf process. Consequently, the perf tool in user space exits from polling and sends a SIGTERM signal to kill child processes and itself. This explains why we observe the tool being 'Terminated'. With the setuid bit a non-privileged user can obtain the same permissions as the executable's owner. If the owner has the privileged permission for accessing perf events, the kernel should keep enabling perf events. For this reason, this patch adds a condition checking for perfmon_capable() to not disabling perf events when the user has privileged permission yet. Note the begin_new_exec() function only checks permission for the per-thread mode in a perf session. This is why we don't need to add any extra checking for the global knob 'perf_event_paranoid', as it always grants permission for per-thread performance monitoring for unprivileged users (see Documentation/admin-guide/perf-security.rst). Signed-off-by: Leo Yan Cc: Al Grant Cc: James Clark Cc: Mark Rutland --- fs/exec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index ff6f26671cfc..5ded01190278 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1401,7 +1401,8 @@ int begin_new_exec(struct linux_binprm * bprm) * wait until new credentials are committed * by commit_creds() above */ - if (get_dumpable(me->mm) != SUID_DUMP_USER) + if ((get_dumpable(me->mm) != SUID_DUMP_USER) && + !perfmon_capable()) perf_event_exit_task(me); /* * cred_guard_mutex must be held at least to this point to prevent -- 2.39.2