[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyfjG1h2zkkGai_VPM8p5bhWhvNXs1HvuWMgxv4RSywYw@mail.gmail.com>
Date: Wed, 6 Jul 2011 11:01:47 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>, Jiri Slaby <jslaby@...e.cz>,
James Morris <jmorris@...ei.org>, Neil Brown <neilb@...e.de>,
kernel-hardening@...ts.openwall.com
Subject: Re: RLIMIT_NPROC check in set_user()
On Wed, Jul 6, 2011 at 10:36 AM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Sun, Jun 12, 2011 at 17:09 +0400, Vasiliy Kulikov wrote:
>> I'd be happy to hear opinions about improving the fixes above or
>> alternative fixes.
>
> No comments? Even "Sigh, what a nasty problem. But we cannot really
> fix it without significantly breaking the stuff. Go and drink something." ?
Thanks for reminding me.
My reaction is: "let's just remote the crazy check from set_user()
entirely". If somebody has credentials to change users, they damn well
have credentials to override the RLIMIT_NPROC too, and as you say,
failure is likely a bigger security threat than success.
The whole point of RLIMIT_NPROC is to avoid fork-bombs. If we go over
the limit for some other reason that is controlled by the super-user,
who cares?
So let's keep it in kernel/fork.c where we actually create a *new*
process (and where everybody knows exactly what the limit means, and
people who don't check for error cases are just broken). And remove it
from everywhere else.
Hmm?
Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
