linux-kernel - Re: [PATCH] mm: larger stack guard gap, between vmas

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: <CAGXu5jJimVeaMxh43LURsK+nJ9RxR0ifnm80W6qfNoJBcU6uzg@mail.gmail.com>
Date:   Wed, 5 Jul 2017 19:45:25 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.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: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 5:19 PM, Andy Lutomirski <luto@...nel.org> wrote:
> On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook <keescook@...omium.org> wrote:
>> As part of that should we put restrictions on the environment of
>> set*id exec too? Part of the risks demonstrated by Qualys was that
>> allowing a privilege-elevating binary to inherit rlimits can have lead
>> to the nasty memory layout side-effects. That would fall into the
>> "hardening" bucket as well. And if it turns out there is some set*id
>> binary out there that can't run with "only", e.g., 128MB of stack, we
>> can make it configurable...
>
> Yes.  I think it's ridiculous that you can change rlimits and then
> exec a setuid thing.  It's not so easy to fix, though.  Maybe track,
> per-task, inherited by clone and exec, what the rlimits were the last
> time the process had privilege and reset to those limits when running
> something setuid.  But a better approach might be to have some sysctls
> that say what the rlimits become when doing setuid.
>
> We need per-user-ns sysctls for stuff like this, and we don't really
> have them...

In userspace, the way that sensible rlimit defaults were selected by
PAM when building an initial environment is to just examine the
rlimits of init. Maybe we could just do the same thing here, which
gives us some level of namespace control.

-Kees

-- 
Kees Cook
Pixel Security