From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 40C1B6B0362 for ; Thu, 17 Nov 2016 16:53:49 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id i88so122926596pfk.3 for ; Thu, 17 Nov 2016 13:53:49 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com. [166.70.13.231]) by mx.google.com with ESMTPS id q71si4856106pfj.175.2016.11.17.13.53.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 13:53:48 -0800 (PST) From: ebiederm@xmission.com (Eric W. Biederman) References: <20161019172917.GE1210@laptop.thejh.net> <87pomwi5p2.fsf@xmission.com> <87pomwghda.fsf@xmission.com> <87twb6avk8.fsf_-_@xmission.com> <87inrmavax.fsf_-_@xmission.com> <20161117204707.GB10421@1wt.eu> <20161117213258.GA10839@1wt.eu> Date: Thu, 17 Nov 2016 15:51:09 -0600 In-Reply-To: <20161117213258.GA10839@1wt.eu> (Willy Tarreau's message of "Thu, 17 Nov 2016 22:32:59 +0100") Message-ID: <874m3522sy.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [REVIEW][PATCH 2/3] exec: Don't allow ptracing an exec of an unreadable file Sender: owner-linux-mm@kvack.org List-ID: To: Willy Tarreau Cc: Kees Cook , Linux Containers , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Linux FS Devel , Michal Hocko , Jann Horn , Andy Lutomirski Willy Tarreau writes: > On Thu, Nov 17, 2016 at 01:07:33PM -0800, Kees Cook wrote: >> I'm not opposed to a sysctl for this. Regardless, I think we need to >> embrace this idea now, though, since we'll soon end up with >> architectures that enforce executable-only memory, in which case >> ptrace will again fail. Almost better to get started here and then not >> have more surprises later. > > Also that makes me realize that by far the largest use case of ptrace > is strace and that strace needs very little capabilities. I guess that > most users would be fine with having only pointers and not contents > for addresses or read/write of data, as they have on some other OSes, > when the process is not readable. But in my opinion when a process > is executable we should be able to trace its execution (even without > memory read access). Given all of this I will respin this series with a replacement patch that adds a permission check ion the path where ptrace calls access_process_vm. I avoided it because the patch is a bit larger and with full ptrace control is much better at leaking information. Even if you can't read the data. But ptrace works even if it won't give you the memory based arguments to system calls anymore. Eric -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org