From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) by kanga.kvack.org (Postfix) with ESMTP id 1D3E66B0375 for ; Thu, 17 Nov 2016 18:28:29 -0500 (EST) Received: by mail-vk0-f69.google.com with SMTP id w194so148804772vkw.2 for ; Thu, 17 Nov 2016 15:28:29 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com. [2607:f8b0:400c:c08::22e]) by mx.google.com with ESMTPS id b31si1624736uab.101.2016.11.17.15.28.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 15:28:28 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id b35so156788012uaa.3 for ; Thu, 17 Nov 2016 15:28:28 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <87y41kjn6l.fsf@xmission.com> <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> From: Andy Lutomirski Date: Thu, 17 Nov 2016 15:28:07 -0800 Message-ID: Subject: Re: [REVIEW][PATCH 2/3] exec: Don't allow ptracing an exec of an unreadable file Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Kees Cook Cc: Willy Tarreau , "Eric W. Biederman" , Linux Containers , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Linux FS Devel , Michal Hocko , Jann Horn On Thu, Nov 17, 2016 at 1:07 PM, Kees Cook wrote: > On Thu, Nov 17, 2016 at 12:47 PM, Willy Tarreau wrote: >> On Thu, Nov 17, 2016 at 11:08:22AM -0600, Eric W. Biederman wrote: >>> >>> It is the reasonable expectation that if an executable file is not >>> readable there will be no way for a user without special privileges to >>> read the file. This is enforced in ptrace_attach but if we are >>> already attached there is no enforcement if a readonly executable >>> is exec'd. >> >> I'm really scared by this Eric. At least you want to make it a hardening >> option that can be disabled at run time, otherwise it can easily break a >> lot of userspace : >> >> admin@aloha:~$ ll /bin/bash /bin/coreutils /bin/ls /usr/bin/telnet >> -r-xr-x--x 1 root adm 549272 Oct 28 16:25 /bin/bash >> -rwx--x--x 1 root adm 765624 Oct 28 16:27 /bin/coreutils >> lrwxrwxrwx 1 root root 9 Oct 28 16:27 /bin/ls -> coreutils >> -r-xr-x--x 1 root adm 70344 Oct 28 16:34 /usr/bin/telnet >> >> And I've not invented it, I've being taught to do this more than 20 >> years ago and been doing this since on any slightly hardened server >> just because in pratice it's efficient at stopping quite a bunch of >> rootkits which require to copy and modify your executables. Sure >> they could get the contents using ptrace, but using cp is much more >> common than ptrace in scripts and that works. This has prooven quite >> efficient in field at stopping some rootkits several times over the >> last two decades and I know I'm not the only one to do it. In fact >> I *never* install an executable with read permissions for users if >> there's no need for random users to copy it. Does it mean that >> nobody should be able to see why their favorite utility doesn't >> work anymore ? Not in my opinion, at least not by default. >> >> So here I fear that we'll break strace at many places where strace >> precisely matters to debug things. >> >> However I'd love to have this feature controlled by a sysctl (to >> enforce it by default where possible). > > 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. That won't be a problem because exec-only memory is going to need to allow ptrace to read it anyway. --Andy -- 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