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 09:50:28 -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 9:34 AM, Linus Torvalds
<torvalds@...ux-foundation.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 }.
>
>  (c) perhaps encourage people to annotate their suid binaries with
> initial resource requirements (and for stack, I mean the existing
> GNU_STACK ELF annotation in particular).

The more I look at that combination, the more I like it.

We already parse PT_GNU_STACK, and we already take the permission
values from there.

So taking the "p_memsz" field from there to mean the stack limit (if
it is non-zero) would be not only simple, but logical and clean.

And so if something ever wants more stack than 8MB, it would be
trivial to just use elf tools to mark that segment.

Ok, I admit that I don't know if there are any sane elf tools that do
this easily, but it still sounds conceptually like the RightThing(tm)
to do.

                Linus