linux-kernel - Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 7 Jul 2017 09:06:10 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>, Willy Tarreau <w@....eu>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 11:10 PM, Kees Cook <keescook@...omium.org> wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> So 2+MB is still definitely something people can do (and probably *do* do).
>
> With the default 8MB stack, most people are already limited to 2MB
> here. I guess the question is, do people raise their stack rlimit to
> gain more arguments? Should I pick a different value for the args?

So I would not be at all surprised if people just made the stack limit
higher when they hit the E2BIG issue in some script.

So yes, I'd make the max args cutoff be higher than 2MB.

I'd suggest we make the code do:

 (a) keep the existing rlimit/4 check (so *most* people will see the
exact same behavior)

 (b) add a static max arg check for something that is closer to 8MB
but leaves a somewhat reasonable stack size even if the stack size get
reset to 8MB

I'd suggest that (b) case just be 6MB or something. Maybe make it
(_STK_LIM/4*3) or whatever, in case we ever end up changing that
value.

Hmm?

                 Linus