From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 190BE3858C83; Tue, 16 May 2023 20:00:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 190BE3858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1684267217; bh=amHY1KJ1H1Ba7J8iiEDL172gjtqD/ncuwoHgOFqQt5M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ooMjwapCgxU5G2x6CCHgqAASuVsXVGpbq5ShRtfbXvSb+3MFFGPJKnC7NNy9hmaE4 g7rOTWYnYKPFX6ekNEQlXkiX2r9JK/P3zqAk3v4rzjsXe4DkD76fjL6/Pi7TBGtu6R fs2vJNCX0zq5W1hPr8lkaDu2rOv+mPQBvvicpzaA= From: "pedro at palves dot net" To: gdb-prs@sourceware.org Subject: [Bug server/30453] gdbserver cannot set breakpoints when /proc/pid/mem is not writable Date: Tue, 16 May 2023 20:00:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: server X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pedro at palves dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30453 --- Comment #4 from Pedro Alves --- So your kernel hardening has a bug, which you should fix. Restricting /proc/pid/mem by default might make sense, but not if the thread that opens the mem file has ptrace permissions over pid. If the caller is already ptracing the target process, then it already has access to all the inferior's memory. If you want to block ptrace, then that's a different st= ory. The kernel already has some connection between ptrace permissions and /proc/pid/mem. From man proc: ~~~ /proc/[pid]/mem This file can be used to access the pages of a process's memo= ry through open(2), read(2), and lseek(2). Permission to access this file is governed by a ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2). ~~~ You would extend these checks to check whether the calling thread is a ptra= cer of the target pid. Somewhere in fs/proc/base.c:mem_open and friends.=20=20 Actually, Mike's patch already touched exactly that code back then, doing: static ssize_t mem_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { +#ifdef CONFIG_SECURITY_CHROMIUMOS_READONLY_PROC_SELF_MEM + return -EACCES; +#else return mem_rw(file, (char __user*)buf, count, ppos, 1); +#endif } so you'd just tweak that -EACESS code to first check whether the caller is a ptracer of the target, and if so, continue on with the mem_rw path. In Mike's commit log, you've already admited "Getting this merged upstream seems unlikely", so this is all local changes to you. --=20 You are receiving this mail because: You are on the CC list for the bug.=