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 E6F21C02182 for ; Thu, 23 Jan 2025 23:55:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26FC06B0099; Thu, 23 Jan 2025 18:55:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F8E26B009A; Thu, 23 Jan 2025 18:55:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09A07280017; Thu, 23 Jan 2025 18:55:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DCE5B6B0099 for ; Thu, 23 Jan 2025 18:55:45 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 81177A082C for ; Thu, 23 Jan 2025 23:55:45 +0000 (UTC) X-FDA: 83040376650.13.83C3363 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf11.hostedemail.com (Postfix) with ESMTP id 904B440008 for ; Thu, 23 Jan 2025 23:55:43 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Fn2HpbE2; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737676543; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z9Ragv1x82SwxtUpkVXr3TYFZXEnZuc/EWqFgnlmJDc=; b=Luba8Taq5F+i8or+grhM4ioyb0E9TLWlXwj4xHJZXsEfaZwfqsGSTgmYSt3L77cHGmWjHj +Hku4s0dgutKRjye8N8tqo4Xzvc1SVWFvmJ1Si8hl0gGAKDwTOU4BpT9ktArU77LDp0GBS yZW0WVnUf9yrd98xifMkheZmteSGdeA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Fn2HpbE2; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737676543; a=rsa-sha256; cv=none; b=3SRK/Z3/HP0sCZ3fnPQo0fcFwNSbXIj/C4tmXWhRTpth13rk5R4A78yZIqv9unfbQ03mGK MTXp3Hj922BgesXjBaXzI08pRLyeVMTon5lWUHjZTB6/Xf294vtI3c6XlxAkaUP6dt0ilN r9QH9O6Fddpc+eSqhPqaMP89cdw/8DA= Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5d3e638e1b4so1410a12.1 for ; Thu, 23 Jan 2025 15:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737676542; x=1738281342; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=z9Ragv1x82SwxtUpkVXr3TYFZXEnZuc/EWqFgnlmJDc=; b=Fn2HpbE2H0ObpyAjRMKWt8oJ7bfNhK3+C4d8M+iAum6MWQQinFbRcg2am9dEWK1yke vmHf+IjPq8jl0Hcms1UbAtzMnKzk4aOum8KtF1rt5IlFRnciDOGn/VR47Wzd14H1utXZ U1tL0tJtKeO93jD/3pwK2/uYuGuNG9y5dylWT4L31lOeHdcMw5JoFolvigh8iuqpPtj5 nI/ndwQ5JQySKn7VTQlopFU1mQaZzuqmCeb+lSubGQIXm5yOVU1Yqy55uNRTueAtTtbG bV7BDpK66johbX5D56vJJrPKax+PO0jxYajxbfoNT+T4tOCI9u2c46SN3G+3W0yG2woj ZXrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737676542; x=1738281342; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z9Ragv1x82SwxtUpkVXr3TYFZXEnZuc/EWqFgnlmJDc=; b=jbpv/I/xowjKL21Gd61QRjUDjH1nvmofMUCQ0E2OvFc88m43zixzFzemzDQDW0cYVq Go3/C6ttNMMVw8m/Vk2zy2nXxneD8+4dUoejQpnLHEl7HxVg1fd04V3g2sZf5T0MfJDx qNP29+91sc994F/bY1ImFLrpp+SMxlO/FFCcWDGomYtjMIsIOMcVyUWR/dhe2oZxeGE8 2Ww2QdWSIqGQ+CBA4LKDo799jH8fvPpwOgfNvkVxOxo/a5ur50s7G25XqIehm2vx1AYJ 7Dgu0laJnAMbkqBgGBVDRv3gVXdpNICByqcSfr6W0Nz3vLAHAiZgq9fIejn40bqcpmAc wJPw== X-Forwarded-Encrypted: i=1; AJvYcCWUg/Ne1czlVo5qzwyOi0T1XhcDev5Kgd7BT8ajDiF+QWD7DZX+wJFweEUBm9dacipxZ4RjZWNsRg==@kvack.org X-Gm-Message-State: AOJu0YyY4/Nyib8935DP9rQ0rg35hT89LLPCqWedyWfPZO9732+LNVlD ikCRco3wacVe57nDcwqBv+cVreT0hqw0UsF95xt7bc4t9KFF4TLokFvMEsWuK408LIF8fmuT4XZ AM8x9lgnQt6TTH7uH8j63l5ZTDeJaZ7MZhpwh X-Gm-Gg: ASbGnctMo36hK+JVqGqQE/aO9cELfozR4Qrr8/Z1g8RRpCbhpPwFuIOk+qLk5PKUXPl E9HfQK6WmS5zRbRqOOBzC/nK1ITlR6nf2JwpdCTExMd7OOQXt8CrSM+pAdIxTyhtjp6JZoev1Dg m7dfEzu6JIi1ps X-Google-Smtp-Source: AGHT+IFGTCYC1Urp8sKTGkSi5p5S/Fc8SFTFb532XbOtDnLlTcDCvS5l/1/sYkHDNjZYgiEvQM+eMoDylP2iU6QViPQ= X-Received: by 2002:a50:9b0e:0:b0:5db:e8ed:5741 with SMTP id 4fb4d7f45d1cf-5dc0c9ed5fcmr146053a12.7.1737676541342; Thu, 23 Jan 2025 15:55:41 -0800 (PST) MIME-Version: 1.0 References: <20250123214342.4145818-1-andrii@kernel.org> <202501231526.A3C13EC5@keescook> In-Reply-To: <202501231526.A3C13EC5@keescook> From: Jann Horn Date: Fri, 24 Jan 2025 00:55:05 +0100 X-Gm-Features: AWEUYZkNff3Q26T9o9EX_TQ_KWMgeFo0Eqakd0uRwk5keM2gA1CnvXc-g9_3J_s Message-ID: Subject: Re: [PATCH] mm,procfs: allow read-only remote mm access under CAP_PERFMON To: Kees Cook Cc: Suren Baghdasaryan , Andrii Nakryiko , 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, mingo@kernel.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, shakeel.butt@linux.dev, rppt@kernel.org, liam.howlett@oracle.com, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 904B440008 X-Stat-Signature: mn53h76t9h1if3rswtc1qkyybhdwaqu4 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1737676543-58478 X-HE-Meta: U2FsdGVkX19e2QgBawMme8EA8kslvgS7+QmQScL2qvtc5vO9ldGfSEAiDSiX5x0qo/GRPrKJvrArhAutxe6YliyB56Il/CoUO2JXTD6F/e00Ym1KWTFlYNrHXMaF+89VdlJkCG0fR2yuEDr7cw13A/JvCBB2t+wR5Djf3ptYSpx45sumBSLKUx35o0PPimy9NPbKHfwCcp3AgFQ5M+Wk1H2mab6AcvMgLsW847E0PvNCBhd5p0PlWUULQ9GDQTVl9ImSQ7r9i53KEpZzV5U7noVGpKcT02uX0sQ+bXaQ7QURkG9mqh9w8cS7M94kjr4JccbMGEnfRy68Bqw8U4h37O7+rE9ardop22Ralf0vjwuk7ZmJt5FO5UuwS7S48veAD9zWw0lnSlXNDeUmleePCs02OVUQUGa82jAcxdl57yyledSkEq+ZrCv3aPvichg/7mZ/94CQyKKH8lLzWzsfrMfbchzXgtqh5EJP4uhPbkadLb/3ssf4QNm0wiaiBe7Nn7vM7d44QsAC94TXoUOOJWsJzAkjzJaFSWn2YyHS48NhwEmgSOsnoRDpXdspn5W7zIu0sYGJwAplMhYWu4CjvA5fg+r9UZvO56+9UcS2sybwr/tfUXeDI8Qta1W4PFYnLReMpGvJVFCm7240XtAZPn2HQu5j49ONymY2CQQlV/AMzJF49ihmFZ7I7HH5REQIT5/LZriRmLh7mFK4FAk72eotLaqPE3isGDyldSekN2+cWnYuPq8PJ95d/NarElfAQhOgazgerkc5r3YaZT9W01cZQl2LZLsC8MDICcgBWzLe/RPyTlGMX9fXDaXojaX/+JhwjMVCmvjGkIX6166IKnv9B+HoMIUEHf0ro/YZezRAcYQxAjXeLegcXAimQ0nEmtSZIQadJ635eqEHzYkcl5tomRCtfzm885lzZmIKmpqmFZZHkmolOR09qgGyTeE+mk1jVG00y64kMzLMs3h 60YEWRCU bT3DlW3wj3pJGaqFg9Vs168XNe37EImgMb/0e9tJncgKreCEenk4Fhkif/bnfFSytt6oL5PmytWALmIbnccm/7GqJ0cvqcvnuFm2vimbJJ11gomHXwiPILMaaGj+M003MDhQytpoEhmC5ZOW2msHlAjxCAL4irI4GG431B1ijuV3Uv4T2QTS20VNV6VOb7GnSKYS2U7FfnTYTXFYBSSmrvpTAav3BACz7vGoRPh41Mq56pOFNYUysD4W3E9puoRMmaaOMNsEO3XuDqS4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.012552, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jan 24, 2025 at 12:47=E2=80=AFAM Kees Cook wrote: > On Thu, Jan 23, 2025 at 01:52:52PM -0800, Suren Baghdasaryan wrote: > > On Thu, Jan 23, 2025 at 1:44=E2=80=AFPM 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, et= c. > > > Currently, access to /proc/PID/maps requires CAP_SYS_PTRACE (unless w= e > > > 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 simil= ar > > > read-only data) access, and in large production settings CAP_SYS_PTRA= CE > > > 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., settin= g > > > up PERF_RECORD_MMAP collection through perf_event_open() would give o= ne > > > similar information to what /proc/PID/maps provides. > > > > > > CAP_PERFMON, together with CAP_BPF, is already a very common combinat= ion > > > 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. > > > > > > 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_PERF= MON > > > seems like a meaningful allowable capability as well. > > > > > > process_vm_{readv,writev} currently assume PTRACE_MODE_ATTACH level o= f > > > 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. > > > > CC'ing Jann and Kees. > > > > > > > > Signed-off-by: Andrii Nakryiko > > > --- > > > kernel/fork.c | 11 ++++++++++- > > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/fork.c b/kernel/fork.c > > > index ded49f18cd95..c57cb3ad9931 100644 > > > --- a/kernel/fork.c > > > +++ b/kernel/fork.c > > > @@ -1547,6 +1547,15 @@ struct mm_struct *get_task_mm(struct task_stru= ct *task) > > > } > > > EXPORT_SYMBOL_GPL(get_task_mm); > > > > > > +static bool can_access_mm(struct mm_struct *mm, struct task_struct *= task, unsigned int mode) > > > +{ > > > + if (mm =3D=3D current->mm) > > > + return true; > > > + if ((mode & PTRACE_MODE_READ) && perfmon_capable()) > > > + return true; > > > + return ptrace_may_access(task, mode); > > > +} > > nit: "may" tends to be used more than "can" for access check function nam= ing. > > So, this will bypass security_ptrace_access_check() within > ptrace_may_access(). CAP_PERFMON may be something LSMs want visibility > into. > > It also bypasses the dumpability check in __ptrace_may_access(). (Should > non-dumpability block visibility into "maps" under CAP_PERFMON?) > > This change provides read access for CAP_PERFMON to: > > /proc/$pid/maps > /proc/$pid/smaps > /proc/$pid/mem > /proc/$pid/environ > /proc/$pid/auxv > /proc/$pid/attr/* > /proc/$pid/smaps_rollup > /proc/$pid/pagemap > > /proc/$pid/mem access seems way out of bounds for CAP_PERFMON. environ > and auxv maybe too much also. The "attr" files seem iffy. pagemap may be > reasonable. FWIW, my understanding is that if you can use perf_event_open() on a process, you can also grab large amounts of stack memory contents from that process via PERF_SAMPLE_STACK_USER/sample_stack_user. (The idea there is that stack unwinding for userspace stacks is complicated, so it's the profiler's job to turn a pile of raw stack contents and a register snapshot into a stack trace.) So _to some extent_ I think it is already possible to read memory of another process via CAP_PERFMON. Whether that is desirable or not I don't know, though I guess it's hard to argue that there's a qualitative security difference between reading register contents and reading stack memory...