[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110930130353.0da54517.akpm00@gmail.com>
Date: Fri, 30 Sep 2011 13:03:53 -0700
From: Andrew Morton <akpm00@...il.com>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: kernel-hardening@...ts.openwall.com, Christoph Lameter
<cl@...ux-foundation.org>, Pekka Enberg <penberg@...nel.org>, Matt Mackall
<mpm@...enic.com>, linux-mm@...ck.org, Kees Cook <kees@...ntu.com>, Dave
Hansen <dave@...ux.vnet.ibm.com>, Valdis.Kletnieks@...edu, Linus Torvalds
<torvalds@...ux-foundation.org>, David Rientjes <rientjes@...gle.com>, Alan
Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org, Andrew Morton
<akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/2] mm: restrict access to /proc/meminfo
On Fri, 30 Sep 2011 23:53:29 +0400
Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Wed, Sep 28, 2011 at 14:46 -0700, Andrew Morton wrote:
> > On Tue, 27 Sep 2011 23:38:10 +0400
> > Vasiliy Kulikov <segoon@...nwall.com> wrote:
> >
> > > On Tue, Sep 27, 2011 at 21:56 +0400, Vasiliy Kulikov wrote:
> > > > /proc/meminfo stores information related to memory pages usage, which
> > > > may be used to monitor the number of objects in specific caches (and/or
> > > > the changes of these numbers). This might reveal private information
> > > > similar to /proc/slabinfo infoleaks. To remove the infoleak, just
> > > > restrict meminfo to root. If it is used by unprivileged daemons,
> > > > meminfo permissions can be altered the same way as slabinfo:
> > > >
> > > > groupadd meminfo
> > > > usermod -a -G meminfo $MONITOR_USER
> > > > chmod g+r /proc/meminfo
> > > > chgrp meminfo /proc/meminfo
> > >
> > > Just to make it clear: since this patch breaks "free", I don't propose
> > > it anymore.
> >
> > It will break top(1) too. It isn't my favoritest-ever patch :)
>
> FWIW, I consider it as a top's bug. It tries to handle failed open(),
> but forgets to reset tty mode.
>
>
> Anyway, how do we expect userspace apps handle meminfo data? Is it used
> as a debugging information only? E.g. admin wants to see how much
> memory is used, monitoring daemon looks for memleaks and running out of
> memory (1)? Or the numbers are used in some calculations e.g.
> calculation of approximate number of parallel processes to spawn (2)?
Well. Both, of course. And more. eg, monitor it and send an SMS
message to the admin when things start to go wrong.
> If we care about (1) only, we may do the same as we do with kernel
> pointers, i.e. show zeroes to non-CAP_SYS_ADMIN users (plus emit a
> sinlge warning in syslog). It will not break top, and top will simply
> show zero counters. Admins who still want to read this information as
> non-root should chmod/chgrp it in boot scripts. (And distros should
> provide a default "debugging" group for these needs.)
meminfo has been around for a very long time and is a convenient and
centralised point for collecting memory data. There will be a large
number of apps/scripts/tools out there which use it. Many of these
won't even be available to us.
All of which makes it very hard for us to predict how much breakage we
will cause.
> If we care about (2), we should pass non-zero counters, but imagine some
> default values, which will result in sane processes numbers. But it
> might depend on specific applications, I'm not aware whether (2) is
> real.
>
>
> Other ideas?
echo "chmod 0400 /proc/meminfo" >> /etc/rc.local
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
