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 D5810C021B2 for ; Sat, 22 Feb 2025 12:05:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FBC66B007B; Sat, 22 Feb 2025 07:05:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AC146B0083; Sat, 22 Feb 2025 07:05:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19B756B0085; Sat, 22 Feb 2025 07:05:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F2FC86B007B for ; Sat, 22 Feb 2025 07:05:29 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 97512C13F1 for ; Sat, 22 Feb 2025 12:05:29 +0000 (UTC) X-FDA: 83147450778.20.77CA8C0 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf19.hostedemail.com (Postfix) with ESMTP id DF8FC1A000F for ; Sat, 22 Feb 2025 12:05:27 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=INii8xYY; spf=pass (imf19.hostedemail.com: domain of mingo@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mingo@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740225927; 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:dkim-signature; bh=eN/Bey951ExHGdbu79wXB25uevLqC91peMtDtU1VFeU=; b=hIF+yUrqzSjWqIkkX2bhwcFYq8My2WHQOyNmjSmcbh0hCqhJs2qwIuUj+AJEvlDv8l7WmR a1YNqVW7LLisZEgoiivy3Wf4hj6hmsx+1FcxvEa413fQlpUDumn0pVHqxNqyy5tszQBpU0 1dUg97aVfXdvN6Lz69KVbxuwbIhLL60= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740225927; a=rsa-sha256; cv=none; b=XvYW+2rlVMvuTVuuloBGBnsnG+A9Vo/bKq3JcQOgFDCnAqOhexahnhpHXitOC6bnolzMNU HcBbalhWNClULOzuhqUQ+TdZam3Mfk+AnXWum+SuO/ooeADaTrk9hJ6hcEAfHDbUXmc7Em IhHBbc+9/hNb5KAd/WvpDBMNLU1J6Sg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=INii8xYY; spf=pass (imf19.hostedemail.com: domain of mingo@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mingo@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id B52BE6114F; Sat, 22 Feb 2025 12:05:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AEE9C4CED1; Sat, 22 Feb 2025 12:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740225926; bh=AvbO5/5GTYZnYvRAUft9DyG/18ymXgC3kPeuTPaKuI0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=INii8xYY+1RfV8oNF/8uhHfZOeG2G+2beEP208/OrWyKS6Vu9JRlM5R1f0jTyU8wF FPB9LDo153HAZF0AOVY7/G1jpIlGe8237KK/wKxbTnAJskL03zN6pyp5HefBud4Wwm CsThjQmHppffyFTLW9hzoMcLzDSas+gBh+wUK44azftJtitB4X1tlTmObHz1CWBF1d Ms6zv6+jFon5I9xbeYIl81D2daPLr1+5GOLR37QuOSNvVAhZBaU6Yd19puPoeHY0oj tcAY8lgtJqUz8/CS5EsrVVZgXtqRPXWUaIcRixha5OhH3YM86J+EBASUKNrvnQhOPc krP+CEjNctZRA== Date: Sat, 22 Feb 2025 13:05:15 +0100 From: Ingo Molnar To: Andrii Nakryiko Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, kernel-team@meta.com, rostedt@goodmis.org, peterz@infradead.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, shakeel.butt@linux.dev, rppt@kernel.org, liam.howlett@oracle.com, surenb@google.com, kees@kernel.org, jannh@google.com Subject: Re: [PATCH v2] mm,procfs: allow read-only remote mm access under CAP_PERFMON Message-ID: References: <20250127222114.1132392-1-andrii@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250127222114.1132392-1-andrii@kernel.org> X-Rspam-User: X-Rspamd-Queue-Id: DF8FC1A000F X-Rspamd-Server: rspam07 X-Stat-Signature: hy43ps5teiruz9t8mdej3jra7s6hdi11 X-HE-Tag: 1740225927-361891 X-HE-Meta: U2FsdGVkX18RiL2hG1wvNNhnubk7m5n0O3Tv/E1kxxHnde1KRjxbx4gmz/7tlLxhLGazwtG89R/JjdWHt22dPNgbiEYG8Rxx6KF6tSFnMo/vk2mpavdnd5naHIpteLmnKQ99Adb2OurJ/XujI7vZNMGpGfsYnkcpusesc8j6Yi04bti7paPFH0XhNUaGM8gwI6mCKRzvdJVZ3D3l2AkWv+V6/eMK2uWmGwd5TAmhkXr9y1rKPn9gb8874auYHjOq9ZC5UAX/CiIm1WO2Or4F0hRz2Wbp5cLLMI2bc72dGngwNRqqod6bMxWM1rPfrQ9X53jaQ3vNXLAYK6OwEbeSn3PbGsgIm6c21zggbO8/lm/X0KdZqIGHCzsGJsma9eRuwIxPB3L+kwgBZR+GqNF0rXOZGx723vfeXoL7YqhBsDe0F3rcY/3bjLX2AOZC6b+uLemVKwwR4wCYrLZ3Ojdl64+eLUVlmj17ZlGlbxvuLh1qPg2NReKfExyQCU27u6aHZPc3RO61uZEmreWoKYFSjsODiUUoU/T20e0veERNqBVKp3iVWgB7zMKxwvaVP+wf7L5H/0xAM8a8TF0s4nCHf8z+zhhpf32lPKYazqew72EijPDadjwKklHaRMrpAq09mWwTvn2g/V6Dtw13Krli+twpXnnkBgofiszDTRJV7fAuCcK0O2NfPsIXGoijnbT8ZcrJgpodBUu8XGfpQNb4dy0isM69F+tUOCmVXilHs/RHnRZGFt+MU2BKRdYb0qsvV3R5aiC7qGdMIIuF/XeuXVvHamYYgyFQVh8HzkwBUUDDkmkfi9NBiNW9FbBRN6KCd+dyiK6q6y3YHVu2GiXxcQpzeb4u+62MfyhZRkOluDEjazKWv7F6AjcIVpv21phSNiM6XLSh7n4+K3MQ0dQdt0CXEBIGjFtd5bOPkEi+5JBjEqAQMhl2doOlECF6ooT2dWsK+mShZIEM+1gWGT6 rtPMZJmw W97dHMjnjD+r/pG93E2QauujvYOQqrgn/hnlNoQvUgbNBuQvdZZy0tjfAYWJtKKoDZFfvFmw25ESCM5XkAqECY744Aw2c/YXP/rBvGRbHutFQ5H3cX0cKxf6jHX1ZHsvV3dAb3uLL7aMTtaOe1/PiFYU1sUYiYIoRqt3HsL/O21P+qw43Psv8purF0lTxJrvebSylAn9HunSncSb1smVIQvKl2sVazYyIl4fnDoFx0JRHK1IoZn0m2ZaGsA== 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: * Andrii Nakryiko wrote: > It's very common for various tracing and profiling toolis to need to > access /proc/PID/maps contents for stack symbolization needs to learn > which shared libraries are mapped in memory, at which file offset, etc. > Currently, access to /proc/PID/maps requires CAP_SYS_PTRACE (unless we > are looking at data for our own process, which is a trivial case not too > relevant for profilers use cases). > > Unfortunately, CAP_SYS_PTRACE implies way more than just ability to > discover memory layout of another process: it allows to fully control > arbitrary other processes. This is problematic from security POV for > applications that only need read-only /proc/PID/maps (and other similar > read-only data) access, and in large production settings CAP_SYS_PTRACE > is frowned upon even for the system-wide profilers. > > On the other hand, it's already possible to access similar kind of > information (and more) with just CAP_PERFMON capability. E.g., setting > up PERF_RECORD_MMAP collection through perf_event_open() would give one > similar information to what /proc/PID/maps provides. > > CAP_PERFMON, together with CAP_BPF, is already a very common combination > for system-wide profiling and observability application. As such, it's > reasonable and convenient to be able to access /proc/PID/maps with > CAP_PERFMON capabilities instead of CAP_SYS_PTRACE. > > For procfs, these permissions are checked through common mm_access() > helper, and so we augment that with cap_perfmon() check *only* if > requested mode is PTRACE_MODE_READ. I.e., PTRACE_MODE_ATTACH wouldn't be > permitted by CAP_PERFMON. So /proc/PID/mem, which uses > PTRACE_MODE_ATTACH, won't be permitted by CAP_PERFMON, but > /proc/PID/maps, /proc/PID/environ, and a bunch of other read-only > contents will be allowable under CAP_PERFMON. > > Besides procfs itself, mm_access() is used by process_madvise() and > process_vm_{readv,writev}() syscalls. The former one uses > PTRACE_MODE_READ to avoid leaking ASLR metadata, and as such CAP_PERFMON > seems like a meaningful allowable capability as well. > > process_vm_{readv,writev} currently assume PTRACE_MODE_ATTACH level of > permissions (though for readv PTRACE_MODE_READ seems more reasonable, > but that's outside the scope of this change), and as such won't be > affected by this patch. > > Signed-off-by: Andrii Nakryiko Acked-by: Ingo Molnar Thanks, Ingo