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 01ECCC4345F for ; Fri, 26 Apr 2024 00:39:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CFB76B0083; Thu, 25 Apr 2024 20:39:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47F2E6B0088; Thu, 25 Apr 2024 20:39:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3470A6B0089; Thu, 25 Apr 2024 20:39:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 158BB6B0083 for ; Thu, 25 Apr 2024 20:39:08 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A0AA61402F4 for ; Fri, 26 Apr 2024 00:39:07 +0000 (UTC) X-FDA: 82049823534.15.6884EA1 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf12.hostedemail.com (Postfix) with ESMTP id BC45D4000F for ; Fri, 26 Apr 2024 00:39:05 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=YT5mQPdh; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.176 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714091945; 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=xyeyYlhjNPdHyGDZj5zbPNqhK8/HMAhLyRxOSloh5f8=; b=I36aWwggIQ0RRUuyFPmd6XeUlqT02QaXHdEPu0hKMIT4nnf9ldZ+vZMfyGDwCXsu7SPeok H+poZD+jVDgXNBqtZEBzDC6PV53JaNWIrFx+4khMhaDHRTxRThzqKZdtvgoXWnaz6JlwHi cwmd9FKtRUb1DgOL9aj5nCaSkYymOTI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=YT5mQPdh; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.176 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714091945; a=rsa-sha256; cv=none; b=YXKpplQp9yAbgjo8A2ImEJbGo7BJBWLDT7XFg5yAIW8VYLa9nvWoXRshSLD4AbzG3xxO2L 1l9Fd/nXHzGuwjBtkQTW9oE8ZQ5iOtSdsLHBHawQbobdlGcHe3pUtmvvvlnAaAd5Uy4SeU oyPfl5NGgcHHemvwp9bBulP0dIPwGBE= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1e2c725e234so21716285ad.1 for ; Thu, 25 Apr 2024 17:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1714091944; x=1714696744; 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=xyeyYlhjNPdHyGDZj5zbPNqhK8/HMAhLyRxOSloh5f8=; b=YT5mQPdhPd+YYIHa0iCT0KgHstBmxcGhptC/5xRJoxRqfCQBdU9G88DMHow8IVSU30 /odwQkJfn/kYZZmmgdd4F9+h/cQKBpdnxU4XIUxPeh1XtrAt/ZlgyqBo+gd0taezKUhn fKzOBOJkFUklc5LXxOybn3fT069ztd9pgYspQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714091944; x=1714696744; 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=xyeyYlhjNPdHyGDZj5zbPNqhK8/HMAhLyRxOSloh5f8=; b=evCsm54rHGYmuGremTP3gA5eEoAPbTIifVhVXh5wODp4HWPRPZwYchujZ2ZOf6uhYD 3PCCJ8UpwsqAsYMO1bMH9u84oGN1HxaqjQivsl+74MD8CyfXOAhwKAzgOM93oUlqtB5g T/B2vhz558f9AQckjM4hoYMtFz84sff7XmN11qX9QAnuufASZczmubz5RAcvrpAl2CkU JWfCoF7jztyxxgDTs1LuvjYNrjbujSlSxdQttm9w5kAwtXRq7a8m+HoDoWiZ+fxrmtc9 4bVj9XXI9lkPvYVA0i7NHeBpkJj3RJEuzwHWpUzTt3LXEgvzK579x3af1tI2hZLDtTX+ PAVw== X-Forwarded-Encrypted: i=1; AJvYcCX3l8+4ZAQLcZTs2nmopaFCyI5ksZ2unr/NCXzEVdDRxsPhMRv8KDCWVLeHlYv6GgLVR1feimHMB11DN16Fkz0tsI4= X-Gm-Message-State: AOJu0YyEKfRTCFExSndtIBAuRsPDu81u9D9BTKe4AM+aqBa9BwsJmpso hsfMcxCj8LprZZ5lNvN+tfT1j5QLpN/k/84ewnCYjdHqu/u44Zr1K2yLFhVfAA== X-Google-Smtp-Source: AGHT+IHuwl3OPPsxNPOtPIxd0SB/ZhDzhbACRb6zBx3eCM0TcAvrfsdWZfXQSNhR2MSNDgZIHy8YNw== X-Received: by 2002:a17:903:32c7:b0:1e8:682b:7f67 with SMTP id i7-20020a17090332c700b001e8682b7f67mr1960481plr.29.1714091944586; Thu, 25 Apr 2024 17:39:04 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id w17-20020a170902d11100b001e42f215f33sm14397208plw.85.2024.04.25.17.39.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Apr 2024 17:39:03 -0700 (PDT) Date: Thu, 25 Apr 2024 17:39:03 -0700 From: Kees Cook To: Andrew Morton 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: <202404251724.47A3F5ADF@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: <20240425164718.e8e187dd0c5b0a87371d8316@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BC45D4000F X-Stat-Signature: tsotnkyeuoxfetrg4pti7enyesdj3do1 X-HE-Tag: 1714091945-410272 X-HE-Meta: U2FsdGVkX19PbuiC0VlNPc5sMoE590n50SEeSlUeXechCosGtYHz64Sz6TSlI50emG2RhVvkz7EZl1GmcOaeUe/7VjmTNV1ZbT8cJ5QMscld5OFB2Bjp3rCavLETeeoDzkX166fWKr58sYHM8a7yE7yVsL5Oh+gb0Q51NYd6tUX8ckjECtzqfi2sUd+c5BvBi2UzDQfSVKmX5fzttDl6laLv20anzk0V7z/Vhg4U0uLn2KU2Lzc5Vr2L19xWvuMe58jyr7F4z+a+rjhlZ0dFNlUORS3lYg0xnDgr5/UkflwWLjlBKNumOxXRBtI7b67H8mlnVJrB7fv45ku3pEjyW90dTv8+j86dGE7bq0JXozJkiQshRKHdnBqfGJHBqo9FbsdJjEHGuzyO4BbbDdfcyzBMfknvMpFNHzQmonPyMXS/xboC2sKSqEWuL+uwFEjU6j7NVpr2PUB4d4F6xFFFInNT97WCgFDyz1ExNZ1lah69Yeaj5y5+qwvUpaLfa4gLMqOfNLrId3dJVjeSIMkKAFiWrTGxn8XplHkGcQbdWu0LuaJ6wfL0Ze9NlPRvqGtURrP1hGraD/6XXiFsHIyyKntefb1Q4HHXgjdFGYNUPcfTBDiiftNl6szuDBxQ6g8RUPY4XrxRG2YNgcecMw6BNf7NVYrNH5pFkqOy7dxduKAY8svxlJcU5AxyYiigN7uZOcSGIZ1k0bcBsdUu2g66LWIKWzTf534x7Me6CxX/yYqX2CEIy6yC/ZJI7KS025W5up/SiLsLnm4OseIOCrMuUK5ByIBHcSbicl5stCO88T9V65soAMcDWGIxJqDwXn/zovMioe2t3IaWw0aSoNKjtJjgeedngBFxfWKKR8gX+r7v3HrlG+K+HUfQsetBvvHTAUMP1B1k59wRsFS8JVr44VOysnp3WSn3w112Kr2rbhe/LOPpUOy046OMWLLXbE4wK+9+KFx2frL0G2abDVM 4SIB7OtP NAe6fZwT0PTujV/CipUHABfTroQJ3nlalRGCay57spN7TRF1QdYzhw/gerkMsYOj+WT9D6/Ki3RZrthDfMbSPpo6ZbpaxnRvJs0rd/cMcLvh1dB1A6aQPs70dzpiLMZaKr7ZW/NyGak7bAfOYdIWHaVegpHORAD9ftT2GaoWDwqTKHzZAe2iNHkb0otgRNpY2sYWLP3N7SOg4RcWXwW6jZF9WJcWmdnYtzxefaggO9uMU92OtltA4+iAH1OYlQVWh3+X76Tj1iZjxdmZEN7aH4VbWinmQbe/wFHSez0SYgQICs8oN4MxOkFVk+Tp00nBANI+BufXxh2Vtneu0I1/tUfIqUERuj4My5OluFYBWN5+NBTJB0apgvmcWCwex9LCZmvAO4Dgw7TtsfY88SQnAnXFYnjGRNl1OFbYih2Qq8+XOJNOlWRv2WtK9NiBasWZ4dD+OQtXNCoD+3g4KB1Fr4cF6npEkRfThOSONFLJ73HFPpEmRjBq2E018wz3E0lEyKzylq5t8LCspy5kFW/Y3V+esRZnfW3Tvkaix X-Bogosity: Ham, tests=bogofilter, spamicity=0.000129, 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 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. That seems an overly unfriendly default, but I guess if you wanted it as a Kconfig setting? Just seems easiest to make distros that enable alloc profiling safe by default but trivially available to root, and specialized monitoring systems can do whatever they want with their /proc file ACLs. This is kind of how all of this stuff works. There's nothing unique to /proc/allocinfo. We do the same for slabinfo, vmallocinfo, timer_list, etc. And I think it's totally reasonable to have paranoid defaults, give the kind of outrageous stuff attackers have figured out how to reverse engineer. Take for example "we can bypass SLUB randomization for the slab from which struct file is allocated [by examining the /proc/$pid/fdinfo/ file contents]" Jann Horn demonstrated[1]. -Kees [1] https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html -- Kees Cook