From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754627AbdGJSiz (ORCPT ); Mon, 10 Jul 2017 14:38:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:48303 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754009AbdGJSix (ORCPT ); Mon, 10 Jul 2017 14:38:53 -0400 Date: Mon, 10 Jul 2017 20:38:46 +0200 From: Michal Hocko To: Linus Torvalds Cc: Kees Cook , Andy Lutomirski , "Eric W. Biederman" , Ben Hutchings , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , LKML Subject: Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Message-ID: <20170710183846.GA19384@dhcp22.suse.cz> References: <20170707185729.GA70967@beast> <20170710131342.GI19185@dhcp22.suse.cz> <20170710155943.GA7071@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 10-07-17 11:24:55, Linus Torvalds wrote: > On Mon, Jul 10, 2017 at 8:59 AM, Michal Hocko 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