From: Pavel Machek <pavel@ucw.cz>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
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
Date: Fri, 26 Apr 2024 10:32:27 +0200 [thread overview]
Message-ID: <Zitmm2SWucJA1Bdb@duo.ucw.cz> (raw)
In-Reply-To: <CAJuCfpGiRFAOp-aqpVk6GRpG=4LEF3XyuV_LijzwDYRHKqHWWg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
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...
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2024-04-26 8:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 20:08 [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo Kees Cook
2024-04-25 20:45 ` Kent Overstreet
2024-04-25 20:51 ` Matthew Wilcox
2024-04-25 21:04 ` Kent Overstreet
2024-04-25 21:21 ` Suren Baghdasaryan
2024-04-25 21:25 ` Kent Overstreet
2024-04-25 21:38 ` Andrew Morton
2024-04-25 21:45 ` Kent Overstreet
2024-04-26 8:32 ` Pavel Machek [this message]
2024-04-26 8:46 ` Kent Overstreet
2024-04-25 22:42 ` Kees Cook
2024-04-25 23:02 ` Kent Overstreet
2024-04-25 23:47 ` Andrew Morton
2024-04-26 0:27 ` Kent Overstreet
2024-04-26 0:43 ` Kees Cook
2024-04-26 0:58 ` Kent Overstreet
2024-04-26 3:25 ` Matthew Wilcox
2024-04-26 3:35 ` Kent Overstreet
2024-04-26 8:34 ` Pavel Machek
2024-04-26 0:39 ` Kees Cook
2024-04-25 20:57 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zitmm2SWucJA1Bdb@duo.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.