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]

Date:	Wed, 9 May 2012 18:13:08 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Maciej Żenczykowski <zenczykowski@...il.com>
Cc:	James Morris <jmorris@...ei.org>, Neil Brown <neilb@...e.de>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: setuid and RLIMIT_NPROC and 3.1+

Oh christ, I also cannot be bothered to continue arguing with you
since you seemingly randomly drop other people from the discussion.

So don't expect any more replies from me.

                    Linus

On Wed, May 9, 2012 at 6:10 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, May 9, 2012 at 5:47 PM, Maciej Żenczykowski
> <zenczykowski@...il.com> wrote:
>>
>> If you return EAGAIN from setuid, because we've run into the hard
>> limit, and userspace doesn't check it, then the exec will still
>> succeed, and we'll end up running the exec'ed code as root.
>
> But how would that happen in practice, and why would we care?
>
> If the application is buggy, it won't check the setuid() error return,
> but if it does the exec, it will fail.
>
> Only a buggy *and*malicious* application that *first* does non-exec
> cases up until it hits the hard limit and *then* tries to do a buggy
> setuid() - without testing the error value - and exec() would care.
>
> But we don't care about applications that *try* to be actively buggy.
> That simply isn't the interesting case. The point of the whole "return
> error at execve()" was not to discourage the actively buggy usage
> case, but the *accidentally* buggy case. And there's no sane way the
> accidentally buggy case can trigger what you describe.
>
> So the whole point wasn't that it "fixes" buggy applications (they
> are, after all, buggy), but that it makes it less likely to have
> accidental problems. It's a "softer" edge to some bugs.
>
> That said, I don't really care that much about the original patch
> either. For all I care, we could revert it. I just simply don't
> understand the point of your objections.
>
>                          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/