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 31764C4345F for ; Thu, 25 Apr 2024 21:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6EB86B0088; Thu, 25 Apr 2024 17:21:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1ECF6B009B; Thu, 25 Apr 2024 17:21:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BFE76B009D; Thu, 25 Apr 2024 17:21:56 -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 7D72C6B009B for ; Thu, 25 Apr 2024 17:21:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 37DFB1C162D for ; Thu, 25 Apr 2024 21:21:56 +0000 (UTC) X-FDA: 82049326632.03.EDF9737 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf13.hostedemail.com (Postfix) with ESMTP id 6F2F720004 for ; Thu, 25 Apr 2024 21:21:54 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3bCDzUxX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714080114; 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=EtyD5p99BjrJVApkdHs/OLSBEw2UhzUQPdUV6pMX96A=; b=D7QMa8s+s2mbMb0zma1idtPxsLRL9ymuTwpEuynamCuwsnjyz2N3ra3hpeUiWsGof/sBfh EmQ5XFeP4eZDZLvdMYLK0frAajnhFcq7gQa52uXGvJWdwON/vA7G32pzeoG/JRFsIoNEd6 3tRxF9qyivHW6fhUupo4IxsNfz21cCk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3bCDzUxX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714080114; a=rsa-sha256; cv=none; b=LDmVZo5J1/+so8fYlADXpsVlnZiK4cpFS3y/vvLMNJu+thhdBHdmVeFo7uE+Oy4GtdDRAn lc/Z+9CK/DsAdNXFaU1YN1m5GVmBc8VwrZuuJa8HmcAXQYYi9aRsmzrHZvOBrKUFzbL527 jGS1RMQp757J8RpJ8lJrvrD2XlCN3lc= Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-de54b28c3b7so1662598276.1 for ; Thu, 25 Apr 2024 14:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714080113; x=1714684913; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EtyD5p99BjrJVApkdHs/OLSBEw2UhzUQPdUV6pMX96A=; b=3bCDzUxXLBYw8lerCbrRJXG0n7gHTipnIWTZFSIS7H9Ey/o/lNdUhMY8vLIID6yf2h 3TmMPQgAYUGgzpYa8RdLV9E2g7d2CnQT3AQ4aiKdIxYchmVPNC/m1FYp1ZE8gab1GLmA xSIu7oTjh9A+rqC72cFn5eWY2b35oODVbR4gq0Shbuy/owm9vkfxJYE+gVbO7qN1jQl8 iCuyV75WpmsXLcYio05S50RONsxxuVUzbMVBU4fTjtMizmj6wFlUFtGuMIvRmNrqlXqT YK+Hmj+XNvX5Q5UjwM6EdOxC5hOzRb976Wb+NaBEvkPh5FEklgeQvEdc9z/gZgbNZ8le rm0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714080113; x=1714684913; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EtyD5p99BjrJVApkdHs/OLSBEw2UhzUQPdUV6pMX96A=; b=w4q+P8GlXvAv8qWxsZqI+7JKs0tv8N6OyEAYFpCVfLbGUOIBBcZI+cmlt6wzkHFjFN DNHLOHm0kIx+VipuRb+f+p0em6ywTCgLIbOptvmwWsf1ruj/LK0xt+RavzlAkqYXymHD ts+MAT4W4GY3sxCdVNk+xzYX9v01xdsc/KLilF/rsAuHIOMgY7F7+1H7fp5TuctyJ1vr bL2BDuf8ilwnaMSQP6/7cGh3G8XIFmQrr7bpqr95CV5S+eXJAgWADgYf2v1lFq8hZ0Hk X26+Jlyo4IhGkT0EIKQNY4jV3GzSIP+92e4BYrLExC4Jx9sa7+3Ky9X7ChDGtLgoiltk HmZQ== X-Forwarded-Encrypted: i=1; AJvYcCUfNlqxMdy2Q4hxydbrk2foENBygcGJw0yc4+dGxbBxibThwjEvu+7LrbgTJJBseZHVid2fQ0sKNUB+tjWLhHy41fA= X-Gm-Message-State: AOJu0YxWb6vg7AlXUovxFpSB/LNAAbcmuMau05AOjJg4oIFX7+WCE5oB sY2Q19NOuZ572AWgMhptX/jSUiIykYU0VisAjX98nUiogrQN+KwNf6hFsRJvdRsqmycWsnu6JmD UTQG/ITy6duaeCjyjgMfhI5f4GbHIZ0PyLAMlaNsx92VMtPJ7UcZm X-Google-Smtp-Source: AGHT+IGgCMvL26KqQgwefwP8N/EfjWTlXm02yahkb/MjrhIhNHaqD5Cu7Uq//LTHtb9KBj8fMiXuAXpow+tVDMKdSG8= X-Received: by 2002:a5b:8d:0:b0:dcc:56b6:6606 with SMTP id b13-20020a5b008d000000b00dcc56b66606mr905731ybp.40.1714080113218; Thu, 25 Apr 2024 14:21:53 -0700 (PDT) MIME-Version: 1.0 References: <20240425200844.work.184-kees@kernel.org> <64cngpnwyav4odustofs6hgsh7htpc5nu23tx4lb3vxaltmqf2@sxn63f2gg4gu> In-Reply-To: <64cngpnwyav4odustofs6hgsh7htpc5nu23tx4lb3vxaltmqf2@sxn63f2gg4gu> From: Suren Baghdasaryan Date: Thu, 25 Apr 2024 14:21:39 -0700 Message-ID: Subject: Re: [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo To: Kent Overstreet Cc: Matthew Wilcox , Kees Cook , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6F2F720004 X-Rspam-User: X-Stat-Signature: ipwptfeq4zniimytd4eyqxgqre8icrjy X-HE-Tag: 1714080114-341292 X-HE-Meta: U2FsdGVkX1/UKJwTwy1pjU7Sik9tIatHETz4A0NhvpHNgQyPjKXmjDrKdR448HEvZ7Y9C6I/OLkCN0O7QHo7kHFTRmU01D8TcA0rhyAqXDMvJwhGLtW4N3MAHVEKF4x/KMWz0EbOqJyjIqtdxm9prAZvsDg9QWM3mMv3D7Gq8Dkw7xKWbDET5FullFjrmmLl+RmEp94ZuIbx2h8cgwG6xr+fxktGfWdYsBXhhKUXE78SCtsFujzwARCWeAsyHeguJMO29+JzB8oTrbPPD5SOjqRRjh+1xU78iRFbPpdxaykJq9CpFpt0cgTJJkgjTUER3suAN5jHwm1zCooYA5TIySPkP+5CRDMOGIW+beML/RxO8t8wyQLYYpQWmiXKl/I80IS1jbxJk4DBLa8NvWNA2ERLnJXUS2uijjB5XvqPegsJTvi/ZgXOASRIwvBstB3g2WiswIYnw4ZiU+LObC/WDlp5DEZBZGlRkCEO3B470iX/GXn25DsmrrUlmHIP1yoYll1DGItokpL3Euxbb0aczIzRQq0UCgDIw8kYEsMK5Ka/IHk0cwMLZY2XLC0x/GURt+KZFG5mK1D9lqETlsaHptuCg4PuR/PfNkSdbIlRPJVeLpVM5XsLYad9oct+pkyNKEZb8IY2GxkgW0eRP0uTCn4LsQ3lL9DS923eqwCnU2npXI/Ino2JV1BJbkntrjcpUxGwht7fg4UyIF3oL1KJqrJpY0uKU/a8q0UhXg5JVMtU9w/LfgOxi+S/swVuXMgPcQVKdxyrw/A0kevkwScsPuRdOttJjj70m6wD4cxhoVv3MB589UzzB0MAewuki4uZbiMbszQRE7lhUVFWG927edB02MV0Rdhl+vM62S0WBq5KBh0/NXJ+IwAk3k12Uh9Z4IfZwaZPMm892NnoMSGQ4azzsR1bZuqTMJ4R/K+VavsCDR63y4iXWyeknEyDFzY/ZF25E50nRiOZl5Vnvyk by3KEcHt Mv2cpEJiCJWAZC5Zdoug41yXIgTScOJOTLSBc8msEm7OHMaalie9/bsNLgvjrrzMBkpCuucFPQ9gs2+XjQ4WoQuTlT/N246/s2jfvFdpipe70oXvNuXzpcSQxjUOijPJ6EiqzlqwMRPDJ3oUmfJUkNhCLESQ45kbhaRELZA5kf/xIcx9Isxl2EHmFxoakOgDsA58Om3itzyPq/sxm+SgMK2Bm/w9aYfgcSq+O/yi5EUWwRyZnMnN25R0SmIT3zeH5Pc9JY+bIbo/ATumrTD8fyWIMYA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000040, 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 2:04=E2=80=AFPM Kent Overstreet wrote: > > On Thu, Apr 25, 2024 at 09:51:56PM +0100, Matthew Wilcox wrote: > > On Thu, Apr 25, 2024 at 04:45:51PM -0400, Kent Overstreet wrote: > > > On Thu, Apr 25, 2024 at 01:08:50PM -0700, Kees Cook wrote: > > > > The /proc/allocinfo file exposes a tremendous about of information = about > > > > kernel build details, memory allocations (obviously), and potential= ly > > > > even image layout (due to ordering). As this is intended to be cons= umed > > > > by system owners (like /proc/slabinfo), use the same file permissio= ns as > > > > there: 0400. > > > > > > Err... > > > > > > The side effect of locking down more and more reporting interfaces is > > > that programs that consume those interfaces now have to run as root. > > > > sudo cat /proc/allocinfo | analyse-that-fie > > Even that is still an annoyance, but I'm thinking more about a future > daemon to collect this every n seconds - that really shouldn't need to > be root. Yeah, that would preclude some nice usecases. Could we maybe use CAP_SYS_ADMIN checks instead? That way we can still use it from a non-root process? > > And the "lock everything down" approach really feels like paranoia gone > too far - what's next, /proc/cpuinfo? Do we really want to go the > Windows approach of UAC pop ups for everything? I'd rather be going the > opposite direction, of making it as easy as possible for users to see > what's going on with their machine. > > Instead, why not a sysctl, like we already have for perf? > > The concern about leaking image layout could be addressed by sorting the > output before returning to userspace.