linux-kernel - Re: [PATCH] exec: Limit arg stack to at most _STK

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] [day] [month] [year] [list]

Message-ID: <20170710183846.GA19384@dhcp22.suse.cz>
Date:   Mon, 10 Jul 2017 20:38:46 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Ben Hutchings <ben@...adent.org.uk>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3

On Mon 10-07-17 11:24:55, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 8:59 AM, Michal Hocko <mhocko@...nel.org> wrote:
> >
> > We will always need some gap inforcement.
> 
> Considering the Java issue, that's rather questionable.
> 
> We really can't be breaking libreoffice. That's like a big classic
> no-no - it affects normal users that simply cannot be expected to work
> around it. For them, it's a "my office application no longer works"
> situation, and they just think the system is flaky.

I completely agree that breaking LO is a no-go and we should strive to
find a way around it. One way to go is to increase the ulimit in the LO
start up script I suspect (this can be done in distributions and work
with the upstream LO to be done in future releases). Is it ideal? Not at
all!  But let's face it, the Java usage of the mapping below the stack
is questionable at best (I would dare to call it broken) and I wory to
weaken otherwise useful mitigation based on a fishy application.

> Now, somebody who explicitly raised the stack limit past 24MB and gets
> bit because he also tries to use more than 6M of arguments - that's
> actually a different issue. Let's see if anybody ever even complains,
> and then we might make it a "only for suid binaries" thing.

Sure, I was not worried about suid only binaries. If we should restrict
the argument/env size then they should behave the same way. Otherwise we
just risk oddities. I am just questioning why do we need to cap the
thing at all. I simply do not see what additional protection does it
give.

-- 
Michal Hocko
SUSE Labs