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:   Thu, 6 Jul 2017 10:52:06 -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 10:29 AM, Kees Cook <keescook@...omium.org> wrote:
>>
>>  (a) minimal: just use our existing default stack (and stack _only_)
>> limit value for suid binaries that actually get extra permissions: {
>> _STK_LIM, RLIM_INFINITY }.
>
> This would look a lot like the existing patch; it'd just not copy the
> init process rlimits.

Can't we just do the final rlimit setting so late in execve that we
don't need that whole "saved_rlimit" thing?

If the issue is the "people can use argv/envp to already fill the
stack", then I'd actually be happier with just limiting that.

We already claim that our ARG_MAX is just 128kB (old legacy). And I
was really happy when we changed our execve() to not have that nasty
array of pages, and we could expand on the array sizes. But we could
*easily* just say "limit execve arrays to 8MB", because while our code
can handle more, you do have latency issues and just memory use issues
too.

So right now we already limit the stack size artificially to 1/4 the
stack rlimit (see get_arg_page()), and we could easily just further
cap it at 8M total - right now people obviously actually run in
practice with much less (ie for me that argument size is capped at a
quarter of that 8MB default rlimit).

I have heard of people who want a big stack due to crazy recursion or
due to just doing otherwise insane things. But needing more than 8MB
of arg/envp? Not happening.

So I think we could easily do that stack rlimit thing at the very last
minute, and not have to worry about restoring anything.

                 Linus