[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100907124656.05353c2b.akpm@linux-foundation.org>
Date: Tue, 7 Sep 2010 12:46:56 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jon Oberheide <jon@...rheide.org>
Cc: oss-security@...ts.openwall.com, Sebastian Krahmer <krahmer@...e.de>,
security@...nel.org, spender@...ecurity.net
Subject: Re: Re: [Security] /proc infoleaks
On Tue, 07 Sep 2010 15:24:34 -0400
Jon Oberheide <jon@...rheide.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@...e.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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
