From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752658AbdGGFPb (ORCPT ); Fri, 7 Jul 2017 01:15:31 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:35411 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbdGGFPa (ORCPT ); Fri, 7 Jul 2017 01:15:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170706043235.GA36170@beast> From: Kees Cook Date: Thu, 6 Jul 2017 22:15:28 -0700 X-Google-Sender-Auth: fixNghzrWnvCzuLBBzKKGzj_iig Message-ID: Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec To: Andy Lutomirski Cc: Linus Torvalds , Michal Hocko , Ben Hutchings , Willy Tarreau , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Larry Woodman , "Kirill A. Shutemov" , Tony Luck , "James E.J. Bottomley" , Helge Diller , James Hogan , Laura Abbott , Greg KH , "security@kernel.org" , Qualys Security Advisory , LKML , Ximin Luo Content-Type: text/plain; charset="UTF-8" X-ccpol: medium Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: >> How about a much simpler solution: don't read rlimit at all in >> copy_strings(), let alone try to enforce it. Instead, just before the >> point of no return, check how much stack space is already used and, if >> it's more than an appropriate threshold (e.g. 1/4 of the rlimit), >> abort. Sure, this adds overhead if we're going to abort, but does >> that really matter? > > We should avoid using up tons of memory and then failing. Better to > cap it as we use it. Plumbing a sane value into this shouldn't be hard > at all. Just making this a hardcoded 2MB seems sane (1/4 of 8MB). > >> I don't see why using rlimit for layout control makes any sense >> whatsoever. Is there some historical reason we need that? As far as >> I can see (on insufficient inspection) is that the kernel is trying to >> guarantee that, if we have so much arg crap that our remaining stack >> is less than 128k, then we don't exceed our limit by a little bit. > > IIUC, this is a big deal on 32-bit. Unlimited stack triggers top-down > mmap instead of bottom-up. I mean, I'd be delighted to get rid of > this, but I thought it was relied on by userspace. I always say this backwards. :P Default is top-down (allocate at high addresses and work down toward low). With unlimited stack, allocations start at low addresses and work up. Here's the results (shown with randomize_va_space sysctl set to 0): $ ulimit -s 8192 $ cat /proc/self/maps 08048000-08050000 r-xp 00000000 fc:01 843 /bin/cat 08050000-08051000 r--p 00007000 fc:01 843 /bin/cat 08051000-08052000 rw-p 00008000 fc:01 843 /bin/cat 08052000-08073000 rw-p 00000000 00:00 0 [heap] b7be7000-b7de7000 r--p 00000000 fc:01 403307 /usr/lib/locale/locale-archive b7de7000-b7f9a000 r-xp 00000000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so b7f9a000-b7f9b000 ---p 001b3000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so b7f9b000-b7f9d000 r--p 001b3000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so b7f9d000-b7f9e000 rw-p 001b5000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so b7f9e000-b7fa1000 rw-p 00000000 00:00 0 b7fb2000-b7fd7000 rw-p 00000000 00:00 0 b7fd7000-b7fd9000 r--p 00000000 00:00 0 [vvar] b7fd9000-b7fdb000 r-xp 00000000 00:00 0 [vdso] b7fdb000-b7ffd000 r-xp 00000000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so b7ffd000-b7ffe000 r--p 002d7000 fc:01 403307 /usr/lib/locale/locale-archive b7ffe000-b7fff000 r--p 00022000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so b7fff000-b8000000 rw-p 00023000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so bffdf000-c0000000 rw-p 00000000 00:00 0 [stack] $ ulimit -s unlimited $ cat /proc/self/maps 08048000-08050000 r-xp 00000000 fc:01 843 /bin/cat 08050000-08051000 r--p 00007000 fc:01 843 /bin/cat 08051000-08052000 rw-p 00008000 fc:01 843 /bin/cat 08052000-08073000 rw-p 00000000 00:00 0 [heap] 40000000-40022000 r-xp 00000000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so 40022000-40023000 r--p 002d7000 fc:01 403307 /usr/lib/locale/locale-archive 40023000-40024000 r--p 00022000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so 40024000-40025000 rw-p 00023000 fc:01 276959 /lib/i386-linux-gnu/ld-2.24.so 40025000-40027000 r--p 00000000 00:00 0 [vvar] 40027000-40029000 r-xp 00000000 00:00 0 [vdso] 40029000-4004e000 rw-p 00000000 00:00 0 4005f000-40212000 r-xp 00000000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so 40212000-40213000 ---p 001b3000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so 40213000-40215000 r--p 001b3000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so 40215000-40216000 rw-p 001b5000 fc:01 276980 /lib/i386-linux-gnu/libc-2.24.so 40216000-40219000 rw-p 00000000 00:00 0 40219000-40419000 r--p 00000000 fc:01 403307 /usr/lib/locale/locale-archive bffdf000-c0000000 rw-p 00000000 00:00 0 [stack] -- Kees Cook Pixel Security