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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/