linux-kernel - Re: setuid and RLIMIT

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+55aFyXP8PRusYYrpAnFfV=eL69ktfQfiGxAH1B-Ds8HH+bJQ@mail.gmail.com>
Date:	Wed, 9 May 2012 16:50:32 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Maciej Żenczykowski <zenczykowski@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>, Neil Brown <neilb@...e.de>,
	Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: setuid and RLIMIT_NPROC and 3.1+

On Wed, May 9, 2012 at 4:46 PM, Maciej Żenczykowski
<zenczykowski@...il.com> wrote:
>
> Doesn't that just reintroduce the security 'hole' in buggy userspace apps
> that the original patch was attempting to fix?

Well, those bggy apps have to be really *odd* buggy apps now. IOW,
they need to do setuid(), and then not execve(). At that point, they
really do have to check the error return, since there is no execve()
for them to check.

In the end, we can do only so much to counter buggy apps. I think my
patch is a reasonable "we can try to give the error at execve() time,
but if somebody does tons of setuid() without ever doing the execve(),
at some point they do have to check the error return of setuid()
itself".

I suspect most users of setuid() are good and check the error return.

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