From owner-svn-src-head@freebsd.org Mon May 15 19:23:27 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1492D6E4BB; Mon, 15 May 2017 19:23:27 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2092838; Mon, 15 May 2017 19:23:27 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 03394125F; Mon, 15 May 2017 19:23:27 +0000 (UTC) Date: Mon, 15 May 2017 19:23:26 +0000 From: Alexey Dokuchaev To: Nikolai Lifanov Cc: Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r318313 - head/libexec/rtld-elf Message-ID: <20170515192326.GB28684@FreeBSD.org> References: <201705151848.v4FImwMW070221@repo.freebsd.org> <20170515185236.GB1637@FreeBSD.org> <6c327032-9eb5-2b0a-39ed-2140144a5a0d@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c327032-9eb5-2b0a-39ed-2140144a5a0d@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 19:23:28 -0000 On Mon, May 15, 2017 at 03:09:33PM -0400, Nikolai Lifanov wrote: > On 05/15/2017 14:52, Alexey Dokuchaev wrote: > > Does it mean that old Linux' trick of /lib/ld-linux.so.2 /bin/chmod +x > > /bin/chmod would now be possible on FreeBSD as well? Does this have > > any security implications? > > This is a use case for fixing accidentally hosed /bin/chmod binary and > not some sort of an escalation thing. You will need to be root to do > this. Because /bin/chmod is owned by root, not because /libexec/ld-elf.so.1 is limiting execution to root only, or is it (I might have missed uid check in that patch [1], but at a quick glance I didn't see it). On a living system, there are plenty of other ways to restore missing +x on /bin/chmod as long as you can call chmod(2), from simple Python script down to manually crafting small binary in hex. > Likewise, with working chmod binary, you should be able to mark > binaries with write access executable. Well, it's not just about chmod(1), this opens what can be a can of worms and I want to know how big it is. ./danfe [1] Idea for security.bsd.ld_elf_exec_root_only sysctl(8)?