Re: Re: [Security] /proc infoleaks

[Andrew Morton <akpm () linux-foundation org>]

On Tue, 07 Sep 2010 15:24:34 -0400
Jon Oberheide <jon () oberheide org> wrote:

> On Tue, 2010-09-07 at 03:51 -0700, Andrew Morton wrote:
> > On Tue, 7 Sep 2010 10:35:46 +0200 Sebastian Krahmer <krahmer () suse de> wrote:
> >
> > > I have been elected to receive the bashing from all sides,
> > > so here we go.
> > > It is not about a new vulnerability or even a new discussion
> > > but needs to be discussed, at least that we have a clear
> > > statement about the status quo.
> > >
> > > Recent i-CAN-haz-MODHARDEN.c has shown once *again* that
> > > certain file permissions make no sense except to exploitation
> > > development. There is no reason to have files like
> > >
> > > /proc/kallsyms
> > > /proc/slabinfo
> > > /proc/zoneinfo
> > >
> > > and probably a lot of others world readable. The symbol
> > > addresses might be hard-coded for a certain targetlist
> > > inside the exploit so you can argue that there
> > > wont be any protection benefit from making it unreadable.
> > > However this argument aint a reason to also leak it for self-compiled
> > > kernels and doesnt even hold for dynamic/runtime content
> > > like slabinfos etc.
> > > It would be nice to have something like
> > >
> > > echo 1 > /proc/quiet
> > >
> > > or something like a umask for kernel-owned proc
> > > entries so that you have a polite default and are
> > > still able to enable it for certain profiling tools
> > > or whereever you need it.
> >
> > chmod 0440 /proc/slabinfo
> >
> > What am I missing here?
>
> You're missing the "secure by default" part.

We're not going to change the kernel defaults, end of story - that
would break far too much stuff.

The kernel provides everything that is needed here.  The way to address
this is within a distro: change the /proc file permissions in
initscripts and fix up all the resulting fallout in the userspace
applications.