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]

Message-ID: <CAGXu5jK9U8Wo=u0N4cZY_xt9TJ5Hyd2O4buxHu5eAqjCUz-PoA@mail.gmail.com>
Date:   Thu, 6 Jul 2017 12:12:55 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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:52 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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?

The stack rlimit defines the mmap layout too:

do_execveat_common() ->
exec_binprm() ->
search_binary_handler() ->
fmt->load_binary (load_elf_binary()) ->
setup_new_exec() ->
arch_pick_mmap_layout() ->
mmap_is_legacy() ->
rlimit(RLIMIT_STACK) == RLIM_INFINITY

exec_binprm() happens after the other stack setup (copy_strings()), so
if we wanted to avoid saved_rlimit, we'd have to replumb how
arch_pick_mmap_layout() works and how copy_strings() performs its
calculations (neither looks too terrible).

> 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.

That would address the argv/envp calculation but not the layout control.

> 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.

We should double check there isn't more than just argv and layout, but
I think both cases could be passed down a value from above instead of
examining current's rlimits.

-Kees

-- 
Kees Cook
Pixel Security