kernel-hardening - Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110905194908.GA2690@albatros>
Date: Mon, 5 Sep 2011 23:49:08 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	containers@...ts.osdl.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Nathan Lynch <ntl@...ox.com>,
	kernel-hardening@...ts.openwall.com,
	Oren Laadan <orenl@...columbia.edu>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Glauber Costa <glommer@...allels.com>,
	James Bottomley <jbottomley@...allels.com>,
	Tejun Heo <tj@...nel.org>, Alexey Dobriyan <adobriyan@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/
 directory v6

On Mon, Sep 05, 2011 at 23:20 +0400, Cyrill Gorcunov wrote:
> On Mon, Sep 05, 2011 at 10:53:58PM +0400, Vasiliy Kulikov wrote:
> ...
> >  
> > +static int pid_no_revalidate(struct dentry *dentry, struct nameidata *nd)
> > +{
> > +	if (nd && nd->flags & LOOKUP_RCU)
> > +		return -ECHILD;
> > +
> > +	d_drop(dentry);
> > +	return 0;
> > +}
> > +
> 
> Thanks Vasiliy! So every lookup will cause dcache to drop previous cached
> entry and alloc and hash new one instead, pretty dramatic, espec in case
> of huge number of files mapped ;) Still since it's not time critical operation
> (at least for now) I tend to agree.

Actually, it can be speed up by introducing the same ptrace check.  If
ptrace check fails, then just drop the dentry, otherwise continue to use
it.  Then each revalidate would trigger ptrace check instead of full
drop-lookup-alloc cycle.  If one process actively looks into
map_files/ or fd/, it will not become significantly slower.  However, it
will trigger 2 capable() fail alerts in ptrace_may_access() instead of
one :)

But I still see one very nasty issue - one may trigger this ptrace check,
trigger d_drop() and then look at /proc/slabinfo at "dentry" row.  If
the number has changed, then the interested dentry existed before the
revalidate call.  This infoleak is tricky to fix without any race.

Probably it's time to close /proc/slabinfo infoleak?

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.