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 AEC10C4345F for ; Fri, 26 Apr 2024 00:43:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 411106B0089; Thu, 25 Apr 2024 20:43:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C18C6B008A; Thu, 25 Apr 2024 20:43:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 288FD6B008C; Thu, 25 Apr 2024 20:43:38 -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 076056B0089 for ; Thu, 25 Apr 2024 20:43:38 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9389D1A0902 for ; Fri, 26 Apr 2024 00:43:37 +0000 (UTC) X-FDA: 82049834874.04.C09D0D1 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf22.hostedemail.com (Postfix) with ESMTP id B2043C000B for ; Fri, 26 Apr 2024 00:43:35 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ef+4eRqL; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714092215; 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=Ep3fnu+2+kL4NWqqCPxqUe7pdWbO780NggADdnS6QQo=; b=jgAeTftkCdi35QAl4mIrbqwGwspIqi3F2WUE7LQQC5uDCy8NAWFjQcVGr5UHxO5QEZHuvB 7gKjs8y8FOPyot4RF85Y0T0wDrXyIo6xn9adKvAlSeJCfFkV2vOqZMXy9W96t0KhTr+fnC 5V7LFebhywMzHqqyN439YbZngC6a7CQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714092215; a=rsa-sha256; cv=none; b=fm8ZkW3LWZ46DpgoKkYC1gmINZO+b/Sz+fkB4/fgA4uMG4d7T/1r1CYZMwNmlvQnXhYDdy 0OIIb3vw2zB3DPHDU14VvXLw36ehS1RdjlZ0tLPLa5u5zfTIe2d7INmwNis0sxVXg/aKWC es597aTkP44QMe+azEtIvBxXnu8tvFU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ef+4eRqL; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6ed112c64beso1596235b3a.1 for ; Thu, 25 Apr 2024 17:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1714092214; x=1714697014; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ep3fnu+2+kL4NWqqCPxqUe7pdWbO780NggADdnS6QQo=; b=Ef+4eRqLqSmvrfkNAZb6Qy4vsh8Ka7n5LTDR9geB4nbbYUmVTR03XmectyRpADNgZ7 uRA9K/C0wuYDDFfEvObARLQgGkTDktF9wD7ufHc28thB5cyTEZ5wLgtqgd8sBSsvMZNP lGspA6Xh5DayoRfuksXyN5qqCVOp192etoquQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714092214; x=1714697014; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ep3fnu+2+kL4NWqqCPxqUe7pdWbO780NggADdnS6QQo=; b=V0q3fpEAR5iXByp+8Wy80m4/7mFph/zlwXLcgbKy/KkWPvNq2Hj3hm8pkV248uFV+2 j4LrZxMlOvQp4Ln0KsI6/xg3w5DnbrthZZEZSBdQk+FpqjF3NoSDjxCI8Cvm8HBW2iMi UstwIS32y0vDAukMYiKTMoltdGuGB5hYObawMgbHkl65hWpSB8H3D1BcZ0qWYpBrl9v8 sSObjneVcZx1E1EVKtIGW3NA4mv5oYqAeRjHrWkI9FbdyhCHtR9WLzlriKaNBnZY2l+u Hu8zQv9wTv72BpEQoABPXUJ7FP98KD3nbxFY+GkAck+fcC/MjBNTn/4YEBjcTK1n/76+ udgg== X-Forwarded-Encrypted: i=1; AJvYcCUI798apa5uaAVtEz9j14w/o03YK7MxMysgctCbEY3ciirAaVVYL7LrTQudHiSUOXRtfoSX3SQVYJpEOsj2w23D0OY= X-Gm-Message-State: AOJu0YzK89XgNVc+pI1MAhYqkxusBiwlqdC22jgp2cT91ktagsAtL95d yjhbqXvXfOil7y1iOWvowY97wmO7izeZlg25WqCZPfKqK7O7Rxxg9brGTH+sLw== X-Google-Smtp-Source: AGHT+IFfxbYgBOhINodVoPFPMJa26HomFVHpDJJrtFFl/bfOguOV0nbw21PtsctDUa/b4FBbEGMD/w== X-Received: by 2002:a05:6a21:3286:b0:1ac:3660:4831 with SMTP id yt6-20020a056a21328600b001ac36604831mr1854570pzb.1.1714092214613; Thu, 25 Apr 2024 17:43:34 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id p8-20020a17090a930800b002a513cc466esm15263915pjo.45.2024.04.25.17.43.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Apr 2024 17:43:34 -0700 (PDT) Date: Thu, 25 Apr 2024 17:43:33 -0700 From: Kees Cook To: Kent Overstreet 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: <202404251740.81F21E54@keescook> References: <20240425200844.work.184-kees@kernel.org> <64cngpnwyav4odustofs6hgsh7htpc5nu23tx4lb3vxaltmqf2@sxn63f2gg4gu> <202404251532.F8860056AE@keescook> <20240425164718.e8e187dd0c5b0a87371d8316@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B2043C000B X-Stat-Signature: j4anm4dhn3cupri8uondxsg4r41iiimd X-HE-Tag: 1714092215-933413 X-HE-Meta: U2FsdGVkX197F9ljlxNIsLldCbqR0ob0uA3mzWTLPiVQye1oDRWZhe9ryLBarVaaRAF9EGYL1FM0nGQjLJGzeKOCXNCEFZ37i/VOqjoRoRq2Az2NuvtzCGI3NXcFhBaRLIxVbPT2FosY7jpZn333P1hwJskOBYIEBGqQGAJ6UvFl5AcaOsGyUip+Tb/MLD9BcoLfb673SDVdZyJypwEzEJJ14NbajtRSzAmt4xE0G1yxeR9PePFT/g23OfoEDt83Gmyu/LGg1xl4RBdjrOhnZY15zA5LIlvn8fflHMTq8zE9gcsuYTJdAwXFXdWHHDGBI9qHnEiia0Oh6OyM3K6P+jFDnp+kTCG7D4/0zX7qRr7qd3BRvPp+PTERCUG4aJkH/x4X+n9RR3JOCnEz//9FxVRfZng4HrW9uL5RwJi17eskjFov3c7pY8KJqneC5HjrkAkzS8j0r2rciiGjUoDE5VwTXyoe0uXJ3WR9AbfnvnvTySnPcn7m+xQVTXdgzxceBZZUEVnrFPrqYXipyTrDxOpfe87l0HZcN4p7WdGW6VUo6U1y3nougxyYdvK4PdvRdBhN5HULjltMw77paR89jLvoqf9AYGmibHx6f6kT54n2jYAUjBxPLNl+8YVWG0Ps0O6KY9/L4K+7cnBA1DVM/N6kU/7ksIIgUAlL2iiaY8aG+JjUFSx6OgRa+YJv47RrdJ3tq6YnnXOk64au1s4l64xNgcyzcY9oqlX9e34pgmYJ9WKr9DEgFpzOiyODqnzLgvv1XNlDwjr4x8hyvZzcic2BurBXu+E4e0C13uftzaSN2qF95K4SV8Y1mKagovY90n5WBPBpC5ZRqm5qtDKEdReMJO7xyn+ehISUY/6AmFpP2+UYA4fna11qszJ9Sg96f7TmnaQBQ5pwLoCYMrWbW/WqFgi/OccGtPHLnetE2lG2JKJl0EsuVtWxHtcpy7ukyIpq5MzsAjUmKDwWHXD ruNWymNW 5lny5XX/bTePxiTe9z8gzn9kX+l8dmL7uDPdtzIK7iO9WUtng3+hFIEUBDxc0UrGELYMpd4zLiT0wP87xFscDTH07XlQPG5C1XMmu0OnG6aFDq4S/i3cMqQH/ehmuXOvoxeONllu9s93VL8r0CCr0TuuFO1jOfweggX2OjZLuYwm51td2wqrbRpv4DaPJcYrWCknbezG6+9cvTTB25YrQrzguBm+WhyyqbfWDuzpVb7z5W9gLWFiQeLakQOYqu2Y4l9pc/vlT0k9oAJhR771J3ms6uLIzS1YsnhhziNp7QzvvpCgW/jPYLnzuKZRpkaxFhTDUJyhx5EaIYJcnAMN6qU+ngdGru2jamtY9ja5G3m5m4N9QSsUUBAROaq29iTK7AYzcDyPOjT2zHpab1pFzeRM4TavQx1V4DhpMEDCiEzggaIF1DxQ33PHzLDfSzI9bTJMJ3MqOvl2R2IM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000607, 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 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... -Kees -- Kees Cook