Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752506AbdGFAcH (ORCPT ); Wed, 5 Jul 2017 20:32:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:49566 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbdGFAcG (ORCPT ); Wed, 5 Jul 2017 20:32:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DE6322C86 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: <1499126133.2707.20.camel@decadent.org.uk> <20170704084122.GC14722@dhcp22.suse.cz> <20170704093538.GF14722@dhcp22.suse.cz> <20170704094728.GB22013@1wt.eu> <20170704104211.GG14722@dhcp22.suse.cz> <20170704113611.GA4732@decadent.org.uk> <1499209315.2707.29.camel@decadent.org.uk> <1499257180.2707.34.camel@decadent.org.uk> <20170705142354.GB21220@dhcp22.suse.cz> From: Andy Lutomirski Date: Wed, 5 Jul 2017 17:31:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: larger stack guard gap, between vmas To: Linus Torvalds Cc: Kees Cook , Andy Lutomirski , 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" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2087 Lines: 48 On Wed, Jul 5, 2017 at 4:55 PM, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook 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.