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 85FF8C4345F for ; Fri, 26 Apr 2024 00:58:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA9A06B0082; Thu, 25 Apr 2024 20:58:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5B3D6B0085; Thu, 25 Apr 2024 20:58:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B21476B0088; Thu, 25 Apr 2024 20:58:42 -0400 (EDT) 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 95E966B0082 for ; Thu, 25 Apr 2024 20:58:42 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 349BCA0525 for ; Fri, 26 Apr 2024 00:58:42 +0000 (UTC) X-FDA: 82049872884.21.A5D9A6C Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) by imf04.hostedemail.com (Postfix) with ESMTP id 4EEA64000B for ; Fri, 26 Apr 2024 00:58:40 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=MIYMK39u; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714093120; 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=pW2nVZcsWCTaWzRE1USWg5C8N+QQoR9xikgyDPIEVfg=; b=2fPrP1AaeLx8Bx/KUNKcH9TB9LzitbRejsBHC1pAYZmlLl0hh3MFu3Zl1MaQjtSFPs83D+ Pzqihl5PyPydrZJ6pwyV0XpPiKR2zt7H8GcpVvOa3nO9XIS/UFDm/860+P6VDX5q0q0tQp wgaQ9G5YdOOsigavFjzNayxHlHqJUVU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=MIYMK39u; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714093120; a=rsa-sha256; cv=none; b=cuqsX7CLb3BjB5H1RfB5Yds46H5OOkkk3YnLPsGHiw35YXtA+RTvknGfOP1szo9PFmkEL2 DVQ3REj52Vz2HF6xN4OkWAQdrScxC1xi71B/UcTUR4kyZqgZnWtQkGgSuoZ5r/aSqFYo/H Ktpu70z44E4gyNKTGeI1VM8EVMDxKPw= Date: Thu, 25 Apr 2024 20:58:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1714093118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pW2nVZcsWCTaWzRE1USWg5C8N+QQoR9xikgyDPIEVfg=; b=MIYMK39u8yqpjVgHB3ze+cLWiWdTjBb7/6od4z7JDRizvyBKuLEo9FWHdzw1M9O9DGD7Vc YQZTYCuXdgW7U3efY7Eb43U+WsAe7thXCkRpi21BS2IcQbM306ApwpLrgYjNUqVkZhPg6e ClBbl9sDKx/xOj87h6WiPC+Y7Hvb21M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kees Cook Cc: Andrew Morton , Matthew Wilcox , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo Message-ID: References: <20240425200844.work.184-kees@kernel.org> <64cngpnwyav4odustofs6hgsh7htpc5nu23tx4lb3vxaltmqf2@sxn63f2gg4gu> <202404251532.F8860056AE@keescook> <20240425164718.e8e187dd0c5b0a87371d8316@linux-foundation.org> <202404251740.81F21E54@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202404251740.81F21E54@keescook> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4EEA64000B X-Stat-Signature: kh4ysmey8a6yio77mtanuqoxt5fdp46k X-HE-Tag: 1714093120-804533 X-HE-Meta: U2FsdGVkX19/ZHjGLg2VTkvx/8Cqt0UOboXL2bTA6x5AyWdKzJeJGLsDGWtNAB4je5g7EXYybM2/+TER2A15Bn3ZUjEBlnoS7r14VYTY0/TVWZKI/mdr78bo4bCkwBKXiUblgmPf+FFYZz2NhxRQJSsU/h4yb44lB3DnZx6j0Dj19U4MG+32cgP9k4hiWAkBABRZRAIpdp95y8gssgVTIt5WFbFW9kJgYwNOOoXoa0lTMl47GrlSp45rV7kbxoEtGLMiExV8gqmDvZ9WW+WzWwzbVC/cLYEWpzQ/sHbmdA/woPiAZbkSkNpOUGrWqcKpyu+/ZTK0tvhe3ntt5yQ7vEsmL0OwM36fBi2I+IMDMfHYWOosiMnyMV4GemQzSQKoevjAocgpGE1RHBVVc/KeSLqsK23LM4VsmnxtPxUJfyARg5RKD/S9hF6jYL2zgDxJ3Pfx1ScIl9BKK4AlphiL5LR7mTVsFeP52AGqZdetAC/QEWZrOBlLCL1MnZ7WhzigARcW+w6WItJ+fhUs4VQPPBI8spt345ky0SNDAQqKcmmxGGKgVaYT6gAGJp+zNfdCHFxR6jjCzDODATC8+roJETu4L2IiFl+6JfxPQDNog1PKUrsvaRL/Ea9hcr5bfcC/walzxY8ZCJaFyfENLIaPF+gSe4BrfToqp3icsru5/HNfLYFfzn5J0VKfkIMQjdAeVRNyw0lsAeu8SYwMZDmxNMcFn7RmgPDvIBfnAs19NtPsT3O/9icGDLE5wlW3R6vD6MxPAgOfnn4V5NOycqQoKl8Ja0MJOVWjcQJQtqVr0iU3r9/8TSZ5MOyepopYC5EZtxzSw6j1prvxKQHCWAORzGsP+E8gJ2GiBVns8G83mW13xbN2q4ofOOg0K6Rk8oRNa0vz2GXPwi0cYy5uJ2v8z6WyVrzyGULHodLNUTIR6l6lwalHTohagnDMPuq1HOHK8qrvz3KYjwMM79CvqNg f4qMQKt8 Iyi7SEfylOE57z2Zy/uGY84a2bwGosmIEcmmQzCfSpqvzPg1VN5iJ+5ynt3A2EWTU8weXBZ8PzIIa19cxmTWWKQdW7XInZilw+QmvYfXEMIiW93sANcRJW19A5ki7wjMg+H6UdM9wVy+jWDWvyDWcR8ob8R2/ZrBoS6WioyH4mp4siVzXbzG2UJ1WL/YyGe9phzzj 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: On Thu, Apr 25, 2024 at 05:43:33PM -0700, Kees Cook wrote: > On Thu, Apr 25, 2024 at 08:27:05PM -0400, Kent Overstreet wrote: > > On Thu, Apr 25, 2024 at 04:47:18PM -0700, Andrew Morton wrote: > > > On Thu, 25 Apr 2024 15:42:30 -0700 Kees Cook wrote: > > > > > > > > The concern about leaking image layout could be addressed by sorting the > > > > > output before returning to userspace. > > > > > > > > It's trivial to change permissions from the default 0400 at boot time. > > > > It can even have groups and ownership changed, etc. This is why we have > > > > per-mount-namespace /proc instances: > > > > > > > > # chgrp sysmonitor /proc/allocinfo > > > > # chmod 0440 /proc/allocinfo > > > > > > > > Poof, instant role-based access control. :) > > > > > > Conversely, the paranoid could set it to 0400 at boot also. > > > > > > > I'm just trying to make the _default_ safe. > > > > > > Agree with this. > > > > > > Semi-seriously, how about we set the permissions to 0000 and force > > > distributors/users to make a decision. > > > > I'm ok with 0400 for now since it's consistent with slabinfo, but I'd > > really like to see a sysctl for debug info paranoia. We shouldn't be > > leaving this to the distros; we're the ones with the expertise to say > > what would be covered by that sysctl. > > We've not had great luck with sysctls (see userns sysctl discussions) > since they don't provide sufficient granularity. > > All this said, I'm still not excited about any of these files living > in /proc at all -- we were supposed to use /sys for this kind of thing, > but its interface wasn't great for this kind of more "free-form" data, > and debugfs isn't good for production interfaces. /proc really should > only have pid information -- we end up exposing these top-level files to > every mount namespace with a /proc mount. :( But that's a yet-to-be-solved > problem... It really wouldn't be that hard to relax the 4k file limit in sysfs.