linux-kernel - Re: [PATCH] nextfd(2)

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]

Date:	Mon, 2 Apr 2012 01:08:19 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, akpm@...ux-foundation.org,
	viro@...iv.linux.org.uk, torvalds@...ux-foundation.org,
	drepper@...il.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] nextfd(2)

On Sun, 01 Apr 2012 15:03:38 -0700
"H. Peter Anvin" <hpa@...or.com> wrote:

> On 04/01/2012 05:57 AM, Alexey Dobriyan wrote:
> > 
> > * /proc/self/fd is unreliable:
> >   proc may be unconfigured or not mounted at expected place.

Equally someone could be ptracing your process and changing the answers.
Both are "do stupid stuff, get stupid answers" cases. Why do we care ???
Lots of other stuff breaks in this case so nobody will be doing it for
good reasons

> >   Looking at /proc/self/fd requires opening directory

Which is very efficient

> >   which may not be available due to malicious rlimit drop or ENOMEM situations.
> >   Not opening directory is equivalent to dumb close(2) loop except slower.

If I've rlimited you to no file handles then you already lost whichever
approach you use. Just abort. Trying to do clever stuff in security
sensitive situations via codepaths that inevitably don't get tested when
you've apparently got a malicious executor is dumb.

> (if someone can set an rlimit they can also force an abort) or revert to
> the slow path.

Or have set a CPU limit or memory limit or more.

Alan
--
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/