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 D0B58C4345F for ; Thu, 25 Apr 2024 23:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED64A6B0088; Thu, 25 Apr 2024 19:47:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E86276B008A; Thu, 25 Apr 2024 19:47:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D579F6B008C; Thu, 25 Apr 2024 19:47:27 -0400 (EDT) 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 B71416B0088 for ; Thu, 25 Apr 2024 19:47:27 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 55B4940678 for ; Thu, 25 Apr 2024 23:47:27 +0000 (UTC) X-FDA: 82049693334.12.4EA1AEE Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 3B3321C0004 for ; Thu, 25 Apr 2024 23:47:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=YEheUZTh; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714088844; 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=YPWhJpQ9rZooPHNvvpdVpo8UKkB33RxbkL7GF+fK2eA=; b=NK7AXqCguPhnkqJERq5h5FjkmZ/RPuSzGkjW3y97ww08j0wRJG82H2MFUlkhH02U77k3YZ c2Z1bkYjYknURcn5K31ZE9gSyDbtGJQaBGnQL6rf9Xh9eJA7a1wPUC5XhDFG5tfy7bFenE VyNlW64GQnvynwAzOpyXVESHAJJom2U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714088844; a=rsa-sha256; cv=none; b=j/iez29n6S1pZRQS48/56s164xOLH1aE7RHFmg930kOarz+PyT9XLB5wSNLa2OQG4HJH/S ASiHkP3NLKI2ZnCaPNOvLC3bkqC3yFb4z1ylWgo/y8bF4PhDjqIUEc1ScrjjfVmrsxK/Ix 0UhckZAfnGODX/wSdEUH7yddEK4XQYo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=YEheUZTh; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 30DAFCE1B34; Thu, 25 Apr 2024 23:47:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2102FC113CC; Thu, 25 Apr 2024 23:47:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1714088839; bh=beAuVYStInSqKxnLk3E/kVyZbTYG4nix+yBzCApaJDE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YEheUZThVQmfzJ+cH66dpEmbGfQvhm2WHLxdoorIxuxKL/2z1s5iFoXnh7sMjkCDh vPzE0Ppm0ZZMYyp5msXChAJq9xRrdbLEeS6ODAb0ttQzkvmtk09NiOq8pyzxzs01IF HF9ukneK6b5kQgqee9SDb/kWWL4Y4+C41KBEi1o4= Date: Thu, 25 Apr 2024 16:47:18 -0700 From: Andrew Morton To: Kees Cook Cc: Kent Overstreet , 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: <20240425164718.e8e187dd0c5b0a87371d8316@linux-foundation.org> In-Reply-To: <202404251532.F8860056AE@keescook> References: <20240425200844.work.184-kees@kernel.org> <64cngpnwyav4odustofs6hgsh7htpc5nu23tx4lb3vxaltmqf2@sxn63f2gg4gu> <202404251532.F8860056AE@keescook> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3B3321C0004 X-Stat-Signature: 4m1xig4hw64rdjeokcp4h7ee6j8doig3 X-Rspam-User: X-HE-Tag: 1714088843-251730 X-HE-Meta: U2FsdGVkX19Mo70jCMQo2/je8hkDVTFaLqXvSyWmPmAPwXEA/rOZzCkwYJz2IDU55+zwio7zZjwDWCd4RspOQadRF7CARRG3AxkY3WJHwQF26QHpwgdC7c0JyXhXwH5+B65xMNUwaAMTr/QTqSBSlm0gCppJFhJi1y4OuJDNm0a9l6NrBBFv5jmnc0mOFrRDf0OVlyLCofXlbdZuDQ4Vmsq5XR8YnohxxTWKORbTY/TKhrf5kXqXjodGUuH5hzl/JBFEIqiloH9JcVlVD6XRZK9ZYyQN5M9l9q0XKC9f4h613n46rdP8AXiS89MOfvtCfnKucfHzuBLcqA06WKvEICYga+RV0vpzB6tuyi5FwABRHqocre1TE5LLrqACtTMqOwrpvk5nly1RnPa4AVzMywAMBeaWBn9/5vPHmHK+ExsQEK1gO8uF4TSbk4Fvn0AgN1L8Rm12wPWHojD1AUIzSCNa7/uKx1OLyFsAXY3SNyrg4bJliqTkeCIBUZQGudX42q173agOYz7zegnjvkD05Ny2rDK222L3dw03WIAYiW8OhlAP3ms4GlXk8xRY0LM+YA0gBGf0mAtXnARlnsMisxSNQvMf7hmhjpkZkp9edStbPaoGiabIgzYHGWvC6MVU7Vf7jSey2NZG75wSc42Oh/rtXNo9sPFv6cz8pJhYs+lSoYI3v4BXh5Ee5NcAluwa7GPBm3CR2z7UPYCJPYQ4y+gHh/ZnGxHpu7KzxP8fSa7Myyz/nvz+OBEg+E/Vsry3zjN3ZDy6bZOtk7vFXTEVtSQpEqbUnZ27qx8CvHs0kCeyuRVkwNPLWZLNx74pCJlvm53E+Z/pB4iM+hZtJd7oF4QeuLiwXt0dZXgQiUIptGxa9Yt5m9//Grs+kPn/aF5m7hYSWcPgaDHpurrl75b+gT5RZKmLrzRQk6zqqmFuLTiR2FUP/po2Sj8FxHiPunxUaWtP8cDZefy/lDmx53P CS66852S +oqHsDqzqJBq8foyviSPLlZ58jM1894pCteY0KUUths7kdRALHU+PIDdHCNFMTPP1uaAoFKHq0cdzM7rTfhmtsR3iop/7ZOvzj9E7HQrJ8dOPjRS8ql/IBtn3ZlqMe/emPISLIxSYd+XGibXzRn1FQrlSuvTqAEmJA+roqKitzlDUa8xpowQzX+U1fmNsnUWWn3qtlYpZLElqMoySUqDtyHGr+/EK1NDg3QB6T/TaEWMFwRpodvMcwB0G9Ozy/eOwLJxutawGv+P8XhvbkW1ikUudfsU1w60l6VUyA/71vRZ4f7Rp3uVnVSG/zaB3k/JNX576FSK+kJ26tggC0FAmCZsfO/ihOtGUFYAkeUh7lAyhFyY= 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, 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.