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

On Wed, Jul 5, 2017 at 4:55 PM, Linus Torvalds
<torvalds@...ux-foundation.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?
>
> I'm not seeing what sane limits you could use.
>
> I think the concept of "reset as much of the environment to sane
> things when running suid binaries" is a good concepr.
>
> But we simply don't have any sane values to reset things to.

I wonder if we could pull some "sane" values out of our arses and have
it work just fine.

It's worth noting that a lot of the rlimits don't meaningfully
restrict the use of any particular resource, so we could plausibly
drop requirements to have privilege to increase them if we really
cared to.  I don't see why we'd make such a change, but it means that,
if we reset on set*id and therefore poke a hole that allows a program
to do "sudo -u $me whatever" and thereby reset limits, it's not so
bad.  A tiny survey:

RLIMIT_AS: not a systemwide resource at all.
RLIMIT_CORE: more or less just a policy of what you do when you crash.
I don't see how you could do much damage here.
RLIMIT_CPU: unless you're not allowed to fork(), this doesn't restrict
anything systemwide.
RLIMIT_DATA: ***
RLIMIT_FSIZE: maybe?  but I can see this being quite dangerous across set*id
RLIMIT_LOCKS: gone
RLIMIT_MEMLOCK: this one matters, but it also seems nearly worthless
for exploits
RLIMIT_MSGQUEUE: privilege matters here
RLIMIT_NICE: maybe?  anyone who actually cares would use cgroups instead
RLIMIT_NOFILE: great for exploits.  Only sort of useful for resource management
RLIMIT_NPROC: privilege matters here
RLIMIT_RTTIME: privilege kind of matters.  Also dangerous for exploits
(a bit) since it lets you kill your children at controlled times.
RLIMIT_SIGPENDING: not sure
RLIMIT_STACK: ***

*** means that this is a half-arsed resource control.  It's half-arsed
because this stuff doesn't cover mmap(2), which seems to me like it
defeats the purpose.  This stuff feels like a throwback to the
eighties.