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 AA85EC4345F for ; Fri, 26 Apr 2024 08:46:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7B7D6B00B8; Fri, 26 Apr 2024 04:46:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E2BE66B00B9; Fri, 26 Apr 2024 04:46:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCBCB6B00BA; Fri, 26 Apr 2024 04:46:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ADBED6B00B8 for ; Fri, 26 Apr 2024 04:46:52 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D7F73A1F82 for ; Fri, 26 Apr 2024 08:46:51 +0000 (UTC) X-FDA: 82051052622.26.4B4CDB5 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf15.hostedemail.com (Postfix) with ESMTP id F409CA001D for ; Fri, 26 Apr 2024 08:46:49 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=EenxUM0r; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.174 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=1714121210; 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=fD6phTLFszOoj2PuCrCjp02WsBZ/dFu3rb01qh85uXU=; b=fkmNTQW6CoIIH43qHuwGvqpGyVP7ZsxQ+cL0S1hMS4wNynioIn1NUOEUvG0r5DSkJIQXOt NaN61CwugRWOFFPQ+J8SbEXImWhYx6jAiTvmY9yXuzzWEG7I1F+XE9GNNMX3hCBOnpCAr4 6jyz6yVg0VIGnsgQqiIap48XmWmVk7Q= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=EenxUM0r; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714121210; a=rsa-sha256; cv=none; b=Au5d5zrogwcGasyyYexboOBQAfmSr3uvH8+chkWSDNwOnzd5JhqNwdkVrxNfbpt6CgqJS+ jZLrnuDhrpISYbiSzucfq6eXIGoRBdULvcvMR/J62iKTV/t0EbUmxYEelJ9FfHfqZw6R83 ycKMuKYGquUyv8SrsaM6Nj465F/dhcs= Date: Fri, 26 Apr 2024 04:46:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1714121207; 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=fD6phTLFszOoj2PuCrCjp02WsBZ/dFu3rb01qh85uXU=; b=EenxUM0ra1YpDLwe8ySCjb/39+3a0W7+RBiOtxGJPXMfE49jWH3Yv/676XOdijykrVANke dsoPiW63bw0jH0SAcj8LWySgngy9sg2BORG8CfHyU68tq/NjgR4ixolL2U1JTZvQ8c7B+N BEDitbYZBUgvaUhA4X8FBE51aSNUFIk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Pavel Machek Cc: Suren Baghdasaryan , Matthew Wilcox , Kees Cook , Andrew Morton , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: F409CA001D X-Stat-Signature: jkgiesm9fke87qw835jrpoied519jimr X-HE-Tag: 1714121209-11229 X-HE-Meta: U2FsdGVkX1+qXwu7cXN2JOHbKYOBPB33/QlkVjGAwxIVVqr1ZQdrtGx7UY0dYTLADG9m/MdcJIMd9HUX2BxthzWOLtzdpWYxNgGiI9GPGQfJll6IMRPOLIctB6WQgb6dGDnV3SzFaVQPdOQGLY+iEMFVhSFzIyn7lg5mmqHvW8NiQNfcTFFq0+wdxZSkSFwGjHIwPKTilTmBbDozmX4CI+EmsoaYsDb07eOW0FT+sxlzO/MSBtwRR03TIxtYHhE+lGsf/u+f+N/wCND7lK596ZKHrRGu+z1vWmAN59Uih+cdXzoMzBQfsXrU7aJkm7oxa7koNkj96B1sNgu7YaBskrC4H4+qU+PnoKNiReJhDEyU+wmS0CXoeIaVubgBWz/TkUi5OWqc1HOys5FGQAkK4/5N8CrqnrU/rOBfHbDHmMuZZzVheS6wr6QPDh+oqC//HtBS3WzwwCnP/DtKSO8sOpiJlvf48VCohsU/KaZiYwo4sJuwGgcos3p8Hk8ENSpo/RXk+mnB9Ie0rADmCbJuoqkqtJRBBSg+iuIqhuLxnKhLf9/XWivNddet8wmZC+lVXomLS5tgIaFY70iegf3CFH2utyZbF/dSL279C16O83qs5+5X4s9n6eslnZQbSnhv4IU5L9a7tngK9IXXj6ywYUZQudnU5cmVJNPp/Yh8vnfzrbxkGqzRV29jjHaKE+QfXigNBFd5MsW9RpBJNzO2FZGButVUdQ+GrduKLxJUNGGjO21ImvmCCpLt1SuReFl/pY9wm64nA+gFxZmk199o9YRu/ml4gVvFRSA7KhYZPeJfXmXpGJNhLcPozm3eiJAD8dIgTe1jAHBW05dv4YJfdTRwurD+xbkCYHNjryq/GYhfSR06dRTH3sluVHa5x1AQA69TvV3+VpbXtfdb9me8j2YhPKqHnv5RETbonItDFRiS5I7K7U7TFHKwHaQpnkzzj96xypv3XAqfsYollZr DA7J+GrB WpO/J+zsa+wULdBuhhXVFagM3HBaE1RTmsLiuc7RP6YrQfVq3Jsk4TMRH6kSIHtPE7MKB0Sz9J3jZ8L31MP5OB7aBEHwyVBaZHblCVoDZSkEo0tDTRipBHQJCMjIMEkOwhrzH 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 Fri, Apr 26, 2024 at 10:32:27AM +0200, Pavel Machek wrote: > Hi! > > > > > > > The /proc/allocinfo file exposes a tremendous about of information about > > > > > > kernel build details, memory allocations (obviously), and potentially > > > > > > even image layout (due to ordering). As this is intended to be consumed > > > > > > by system owners (like /proc/slabinfo), use the same file permissions 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? > > CAP_SYS_ADMIN is really not suitable, as it can do changes to the > system. On working system, allocinfo is really not dangerous, it just > may make exploits harder. CAP_KERNEL_OBSERVER or something... There's _really_ no reason to use capabilities at all for something that has file ownership - just use a group.