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 C921BC54E71 for ; Fri, 22 Mar 2024 17:25:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 401F16B0089; Fri, 22 Mar 2024 13:25:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B2896B008A; Fri, 22 Mar 2024 13:25:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2534C6B0092; Fri, 22 Mar 2024 13:25:26 -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 169136B0089 for ; Fri, 22 Mar 2024 13:25:26 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D8BC5C13F0 for ; Fri, 22 Mar 2024 17:25:25 +0000 (UTC) X-FDA: 81925351410.05.38DDF89 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf26.hostedemail.com (Postfix) with ESMTP id 69877140006 for ; Fri, 22 Mar 2024 17:25:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711128323; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u9YSuQR6gaiXF4X+tQfn3Hn0te5KWmVS7WR4LPt6z3o=; b=Ym0o+8h6yuiD+IqcrpUkJUN0weqKEhQop4FmbP+jhAVCpVwFdpa00ZZKjNf9pOyl7Q8e9A oLVzPtTxJtt2HfdHuVrghwhFPrZE/vX59ufZHG8dI1v435FALqAHfI1oyYEpKqF9JPqbya uB1F243S/6LltM7RvK0ibaqoTQQSE/0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711128323; a=rsa-sha256; cv=none; b=jyuCT633fhmW21wTk9t08e/uO4D1w5FVgSZewfa/WsHjfjSRSUv3D0X0sNZyupIENRrfKi 0GcWlq4e77a4kRziqi6DhOLsjbdtKO1I28EnrxCVVrRzcawJRB1w/x5ecLB+m7ksgZ+70Z T3zzWHgTeSuSWTqH09n9Xp/ht07DaYU= Received: from in01.mta.xmission.com ([166.70.13.51]:59970) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rnids-009kpI-Kq; Fri, 22 Mar 2024 11:25:20 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:53186 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rnidr-001ecQ-FZ; Fri, 22 Mar 2024 11:25:20 -0600 From: "Eric W. Biederman" To: Leo Yan Cc: Alexander Viro , Christian Brauner , Jan Kara , 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 , Al Grant , James Clark , Mark Rutland References: <20240322162759.714141-1-leo.yan@arm.com> Date: Fri, 22 Mar 2024 12:24:54 -0500 In-Reply-To: <20240322162759.714141-1-leo.yan@arm.com> (Leo Yan's message of "Fri, 22 Mar 2024 16:27:59 +0000") Message-ID: <87zfuqb2mx.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1rnidr-001ecQ-FZ;;;mid=<87zfuqb2mx.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18snvkqDraPiZ7Bkn94EiEyuPU/BkxIg2g= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] exec: Don't disable perf events for setuid root executables X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspamd-Queue-Id: 69877140006 X-Rspam-User: X-Stat-Signature: hgi8yg1pjikd39kc7r6ugwqjq7j57ddq X-Rspamd-Server: rspam01 X-HE-Tag: 1711128323-392184 X-HE-Meta: U2FsdGVkX18qjhsNzASMDn9dqNPUUdIcyv6qrzLYgnesBS3KqXxAvyXdTQo5cAGPxhu3i+0DyrrXKwZa/tlu8jaxAT6GVHfTN2k16cW892Z/zHMetfXxPhRQNqN9iN0wXlWV6x5UaZlofLOZkrpb6IJ1GLyEyMNdbcgm5lMzlDfWkANuO744B4m0YcvBEQOeJ0R4dqDTllyOy1G01CappjYj8czwBot2tsOd1e/3gUOPESIJyMGq6PbJBbB/vCKxp/LYa34KO3FcdbcKQcCi5FCp2PW+YyYQy3/0omwsWAoQpUzsj1iqF06v2K0sXOMdDJJDlTMIQr0gwHhKmrMku1Laz5BuAMY1VzbKw988SXwhz1hYpIh6jvtnDiDxfr85qlw7ZdleNaLmAvZTG0WuRnBeFxf/UoqZViY/2zkfAl2uzfEzlGPlFuhcTHa4AoxpBe1gbki9En/25Cc0UO76Dh21U+cEG6dP72Vp9KmH35mZRmGshDCvKGzVwaCLwVuW576jmXELVW2PHbaQ6iDlAlNPVCGlVpULGw2+6VnQLKJ3FD58+sZeCFyFZy5+K1kwxZCyQ6/eZZT0t28IVf0eyULZD+65MgxjgmobyjspsSA4Qg42eFxZIn+I+gxc3AKk+035KiL2SWD3CtnUdzkGelgzcXaTE6lCDqhAWAc7/s6BMUmnGqTBgybD5jLVAJoqv4CfSxcV/INfOm1ZG78WC0R7U8xf+Ej9sa1OAoKCBkPYX+1otfkJ4xa5mFFBs3D0V3yi62MsudRR4kFcklzF3HrWRjpPYpw5qAF9tQ4mW223as+j1O/tmsYs0CWun72wmxCkwl0Cq3IPvSO7BsoH/fnLsDjrZeIXBgGHQTRrhxkPf4B+iCngrxb6kvUV+qlHzT0KZo1Lbxqq2VlQpUxZ3+ufZMkoz+2ZPhm2wN+cRMB1m1P/OHE3RmmQljwArsftDkWbY5KpDX8vm5zW00z OwplamJl 4VVano9qbfST1e8dYlsjApBZngzWRZonFw9TW+u25GX+PiKs4mwEOkj3xUNafkEHMdgiZQUF4yI7ZUBcKF+lGVd94cw== 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: Leo Yan writes: > 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). This code change makes no sense. The logic you are attempting to implement, allowing performance measurements of a setuid application if it has sufficient capabilities does make sense. perfmon_capable tests if the current program has sufficient privileges to use perf, not the program that enabled performance measurements. The location perfmon_capable is being called in the new executable is after the new executable gets it's new credentials. AKA the suidroot has already happened. So it will always succeed for suidroot executables. I suggest you take a look at ptracer_capable that is used to test if the ptracer has sufficient credentials to trace a suid root exectuable. Eric > 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