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 6560AC02182 for ; Fri, 24 Jan 2025 00:59:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADC606B009A; Thu, 23 Jan 2025 19:59:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A655D6B009B; Thu, 23 Jan 2025 19:59:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DE0D280017; Thu, 23 Jan 2025 19:59:57 -0500 (EST) 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 665C86B009A for ; Thu, 23 Jan 2025 19:59:57 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 827AA14097B for ; Fri, 24 Jan 2025 00:59:56 +0000 (UTC) X-FDA: 83040538392.20.1DA6DA6 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf14.hostedemail.com (Postfix) with ESMTP id 86033100015 for ; Fri, 24 Jan 2025 00:59:54 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fdgdT09Q; spf=pass (imf14.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737680394; 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=HGJ+LOFQsueZjAbC0cPrdsYkdCGRoW9eQBPBsAKNZBw=; b=RWMjz6ZmS22Cec2wDc17S125DWQlVutREnGNfHwLq+MtSCCHoOiBtTh56ttsBksDNv5rlt bOWXWF5x11Ogq2TkPC1fvTP/4xyL3qz87VRixWaS96zRFWZksWLgOHCGcIDOnJnYrff1fM HrKhfUgUaLr3cGjPkpvFQuu07J20hzg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737680394; a=rsa-sha256; cv=none; b=Dya8RO2UH+nuAA8NroeU1YblVhOvlEg9YT10gKnbWetk8wmDl+eSumV1akDWKNdlGpcOnA 6hTuTU1UThZSTZ+kk//rni8ZvhQc0LqVRirBtf2bJyZCS0BbCRald4Jn+RmgOfsQDQMyTV VAbU87Q8BoY/tb4UiE/xWUKdK/RYnes= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fdgdT09Q; spf=pass (imf14.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2166022c5caso24755035ad.2 for ; Thu, 23 Jan 2025 16:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737680393; x=1738285193; 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=HGJ+LOFQsueZjAbC0cPrdsYkdCGRoW9eQBPBsAKNZBw=; b=fdgdT09QTKc2kuQLqO76IAanGHTpBipTnY3IdIBIyORD4fXHSRFFfWQLsM7Fhh+Z4N ZpW9HIgqG7hiJfLI3R4pID9Kk7tzqnu9CnzEUyeemHtPJEhK/NyylwVjBCFIY7OML70c ULXUlcmO9pvh0+ThutRHiBgeKhHWg7au7n0IMlNtu34CHIY2YoVA6ZgvTiCwn/hFUXny gw9L2k5lmhOyb0k0XWBXmEz+uVJCoRLwjW9T0kYVtJke/7TSMbOhJVfXPPLrUXrg9xDJ u0krZrlDnnah9g9Axl/78vT7owDXIfiq+UA1Nv8NHIl1nb5hj+Rp/RGLAkWgis7Ww/o4 Xxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737680393; x=1738285193; 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=HGJ+LOFQsueZjAbC0cPrdsYkdCGRoW9eQBPBsAKNZBw=; b=Gf8u7gJEVp0E3m/W0uJcn2Cc08yDWdWH/ePYnNaWqDfAx0w3jejwVvE+7MZpcWMNvb C4ECw0MtTxgEnKwEgarNisJIN3Blm5I7TRScF7/VAXajjA+NvXSukAZaI3soVdmiMrUT whA7uabfv6MhXZrxvH0HtAULatp6Hqox5EFLuvmV0YjxVuherDbIS6Z62gUIQUeET0KX 2G4HGTYRt0McZedO9BqjU7FYc3wkv6KwZr88Yqbs1YAolakqOXhRX40Mu3DppEjSgnlM nAuFo+xYJcXuPEA/ggGmJp4Op788vKjAZrNu1dTe9BY/jGkzpN+U+dOIMxXf7XKcuBlc j8Bw== X-Forwarded-Encrypted: i=1; AJvYcCXgH60hQDEH+lglqoXOsseR9TPYN9VGhMOhza7c0nPd/jLA/odyD4H27mx8ygqTejwVgsoJz+Hpfg==@kvack.org X-Gm-Message-State: AOJu0YzbIbIUn4XD6z7gxVbuzCBSa5FmRzc0btwDxuYIrLErhw9HmRZx 2bPFxl4rs+lUk6yD/6a6CJjT2wuHgWkb18vz4aHv5hhdVh+XiEsyiJd/of1sxSY1rIcowu1olJu k6TUlSOupqf7oynjy9fy2Qbpl4Fc= X-Gm-Gg: ASbGnctyClVF8WscjtQEXLzK33Fm9GTRK9M+8qc1+tiY8nUJzhBtaya+ytSWTFbBwk6 J42B8OVfCuMEnwQ4nZ4c9OYyUvh8GDPlQxXggnQiRn/z3iLdrosPaM/64mDcjooeWEoVLWxhSok R2yV+DSTMY4nrF X-Google-Smtp-Source: AGHT+IEUIz9scdrVFJ+gtZjs9wyWB7JNdYwpMDbqC2wtWVPcS47Yd13fC8PGpZo55BBHcmqGMYisS1UI28edrLiekgc= X-Received: by 2002:a05:6a00:3cd3:b0:727:d55e:4be3 with SMTP id d2e1a72fcca58-72daf9e0919mr39848627b3a.7.1737680393052; Thu, 23 Jan 2025 16:59:53 -0800 (PST) MIME-Version: 1.0 References: <20250123214342.4145818-1-andrii@kernel.org> <202501231526.A3C13EC5@keescook> In-Reply-To: <202501231526.A3C13EC5@keescook> From: Andrii Nakryiko Date: Thu, 23 Jan 2025 16:59:38 -0800 X-Gm-Features: AbW1kva6NRq7GYf8siQt0N3qPLCqEdfanjjoZdLOdZlkCjA2qfdcH_vSoTjXlf4 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, Jann Horn , linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 86033100015 X-Stat-Signature: tem65sboe5as5r4fjte7fkfpfwcct5w3 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737680394-335164 X-HE-Meta: U2FsdGVkX1+X3N0rsHGLLZitC5c5VgNgxyoVBTMzw+inUAnGg9nHbGzUwF+PxL7ohiQatN16DAQJWj+KUKSjaBExVn55voXb88U9xyYa92BKhHHqL7r7VjErY5lMq9uxG+oS1ErYna86ktI582Zy1jD04LlBxMHuOOKaYSGJrrtrfYWUiXyzfYIOLGrLdaiVgq0eiiALiNOvTw7ML+mH6KHNg3thTwzQvyH0nTQ6GQIrMyMM2HHtcGmhdmoudE9Zus4Fpb4w4d0GRD4fjEJq6LDVQZBJAze7PNwIgaZ1kDenOGZ/QOMxFw6mOoTopyCWK3VKSZsU92hZIzlQzLS1nSYFzBMlaEf/KEnUgLxpg5W4NuuvwghDaUijNY7VGODlPdN2KNHah4TZnmYngLhgvZEUg+GGPK/9nOCVW0R4YCL0ZobZ+z+SUVNNi8j8QtKMLcfHazjwiD8RRUbccmrTPXxlHooBPdd/qLD8sv8dAVvoTu/OmnCrTuaG4sRqVOSZXKCru0eQE5FmsGuFvuHNsOv1z7aT/3ZVcCxvxRwURKMQXRntO+EyWp4g4a9elvCd9DFhjBUoAnT3wW3sSPf+LCDisOgUjdFJnivpkDqu5XRLzDVnHbd35keiRA4fHyGvWDl7W4xI9Zy44aSUoZ54qsf7d6Hijcjm6gHkRWWOGbe1hchshOUtq/HIgpNmvYsO2Wj1XDSvePeD5hb4B6pLM9/dZCL4HcBkuE4it3dNb10enV85/JjnH+WxgPFjd0ZJPkxsehyy0cuzAI0LRJKuSENrOI4jBzrmFdYDBPBpkKb2muPgvSzXsxHxUK57TaXrFFPL8ebtQsRklu46IhqzYUEgSPbG09VKKChxuzHSwnyyXYxqmOJJcqVQCf3MS2zohy+gTb++4y5hO9wt0iIuXljOZHG1sjvaE+xW7B/qFMJIxq0o23ayQ7dRJjyiyD/BjGIFo6DP9ACO0l4eJRC hD1ry4nD 4kzwsXONN0mTgX4TxXE9xQl/k+jVwSZI1Ov3VZto3i5VqhWJzdnbOXwqvAmHeC4Y0IdehbGGQWHBoCMGYWwjEhttbS0R0/XDdTsudm3P71pU1WjuGrJvdtN7SMOdJOpA00iDalDwP8vYC4xEZd5jhC85QrK7ueZ42ARCCSiH8HQppQvEk7mgog4RGO8jrVX9mT4bo4Dr4RvVZy03vduUx6no36sbzxl+zYsVmnrWpYYoYE7DAM+XwtkHshSwHHnvr0heyYTvpatT6YajGH4ChuonYVCRw1BONr2c4HQH18SVYjMR1xsY5FkVbKsn020jjXaGz9uZ+l/n4ruYFIZKiLd5OCQcTDOghWPazCYjWvQhJwGHwabUDM0ca4SdmozsJ4TzS3o0dlp4M/95UfzLcWXVGKMwTbmFIP9bS X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, 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 Thu, Jan 23, 2025 at 3:47=E2=80=AFPM 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. good point, will change to "may" > > So, this will bypass security_ptrace_access_check() within > ptrace_may_access(). CAP_PERFMON may be something LSMs want visibility > into. yeah, similar to perf's perf_check_permission() (though, admittedly, perf has its own security_perf_event_open(&attr, PERF_SECURITY_OPEN) check much earlier in perf_event_open() logic) > > It also bypasses the dumpability check in __ptrace_may_access(). (Should > non-dumpability block visibility into "maps" under CAP_PERFMON?) With perf_event_open() and PERF_RECORD_MMAP none of this dumpability is honored today as well, so I think CAP_PERFMON should override all these ptrace things here, no? > > 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. As Shakeel pointed out, /proc/PID/mem is PTRACE_MODE_ATTACH, so won't be permitted under CAP_PERFMON either. Don't really know what auxv is, but I could read all that with BPF if I had CAP_PERFMON, for any task, so not like we are opening up new possibilities here. > > Gaining CAP_PERFMON access to *only* the "maps" file doesn't seem too > bad to me, but I think the proposed patch ends up providing way too wide > access to other things. I do care about maps mostly, yes, but I also wanted to avoid duplicating all that mm_access() logic just for maps (and probably smaps, they are the same data). But again, CAP_PERFMON basically means read-only tracing access to anything within kernel and any user process, so it felt appropriate to allow CAP_PERFMON here. > > Also, this is doing an init-namespace capability check for > CAP_PERFMON (via perfmon_capable()). Shouldn't this be per-namespace? CAP_PERFMON isn't namespaced as far as perf_event_open() is concerned, so at least for that reason I don't want to relax the requirement here. Namespacing CAP_PERFMON in general is interesting and I bet there are users that would appreciate that, but that's an entire epic journey we probably don't want to start here. > > -Kees > > > > + > > > struct mm_struct *mm_access(struct task_struct *task, unsigned int m= ode) > > > { > > > struct mm_struct *mm; > > > @@ -1559,7 +1568,7 @@ struct mm_struct *mm_access(struct task_struct = *task, unsigned int mode) > > > mm =3D get_task_mm(task); > > > if (!mm) { > > > mm =3D ERR_PTR(-ESRCH); > > > - } else if (mm !=3D current->mm && !ptrace_may_access(task, mo= de)) { > > > + } else if (!can_access_mm(mm, task, mode)) { > > > mmput(mm); > > > mm =3D ERR_PTR(-EACCES); > > > } > > > -- > > > 2.43.5 > > > > > -- > Kees Cook