[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100913212406.GA11053@1wt.eu>
Date: Mon, 13 Sep 2010 23:24:06 +0200
From: Willy Tarreau <w@....eu>
To: Marcus Meissner <meissner@...e.de>
Cc: oss-security@...ts.openwall.com, Andrew Morton <akpm@...ux-foundation.org>,
spender@...ecurity.net, security@...nel.org
Subject: Re: [Security] Re: /proc infoleaks
On Tue, Sep 07, 2010 at 09:19:03PM +0200, Marcus Meissner wrote:
> > > > 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
> > >
> > Heh, indeed. :-)
> > Would it be a bad idea to have proc_create() use a more strict
> > mode so it is non-leaking by default?
>
> Yeah, sane and a bit more strict, defaults are missing.
>
> The little pieces of information leakage out of the kernel should be fixed,
> to raise the bar for kernel exploits in little steps at a time.
Personally, I don't see why slabinfo could represent a threat.
I'm regularly using it as a normal user just to check where all
my RAM is going from time to time. The more we restrict access to
harmless information, the more we'll have sudoers in the wild for
special users who need special accesses. And sudoers are generally
not as well managed as permissions, believe me ;-)
Cheers,
Willy
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.
