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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFyrSNTh3B7L=Lq1L_Hz=0NEPC95TWmo2-W9odKi+80XJg@mail.gmail.com>
Date:	Wed, 9 May 2012 12:03:47 -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 Mon, May 7, 2012 at 1:13 PM, Maciej Żenczykowski
<zenczykowski@...il.com> wrote:
>
> The application was relying on setuid failing in order to do resource limiting
> (the man page for setresuid documents EAGAIN as the error you'll get if you
> can't switch to the new uid because of RLIMIT_NPROC being exceeded).
> It would detect the error condition and slow down.
> Now it doesn't get an error back and can grow out of control.

Ok. Maybe we could change the logic in set_user() to simply just check
both the soft and the hard limit.

At the hard limit, we just fail it. At the soft limit, we mark the
next execve() for failure.

That would seem to be a very natural model, and it would mean that you
could get the old behavior by simply making the hard limit the same as
the soft limit.

Would that work ok for your use case?

Trivial (but TOTALLY UNTESTED - so maybe it doesn't work) patch attached.

                     Linus

Download attachment "patch.diff" of type "application/octet-stream" (956 bytes)