From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932141AbcHZR7b (ORCPT ); Fri, 26 Aug 2016 13:59:31 -0400 Received: from mail-qt0-f175.google.com ([209.85.216.175]:36284 "EHLO mail-qt0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbcHZR73 (ORCPT ); Fri, 26 Aug 2016 13:59:29 -0400 Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords To: Florian Weimer , James Bottomley , Josh Max , viro@zeniv.linux.org.uk References: <1471838494-29672-1-git-send-email-JMax@mail.greenriver.edu> <1472141735.3489.5.camel@HansenPartnership.com> <9856acd1-cab7-2691-1c89-279fbfe53e19@redhat.com> Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org From: "Carlos O'Donell" Organization: Red Hat Message-ID: <9906de02-1def-22f3-da7a-1040c65d09fd@redhat.com> Date: Fri, 26 Aug 2016 13:59:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9856acd1-cab7-2691-1c89-279fbfe53e19@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/26/2016 10:55 AM, Florian Weimer wrote: > On 08/25/2016 06:15 PM, James Bottomley wrote: >> On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote: >>> This patch allows binfmt_misc to select the interpeter for >>> arbitrary binaries by comparing a specified registered keyword >>> with the value of a specified binary's extended attribute >>> (user.binfmt.interp), and then launching the program with the >>> registered interpreter. >>> >>> This is useful when wanting to launch a collection of binaries >>> under the same interpreter, even when they do not necessarily >>> share a common extension or magic bits, or when their magic >>> conflics with the operation of binfmt_elf. Some examples of its >>> use would be to launch some executables of various different >>> architectures in a directory, or for running some native binaries >>> under a sandbox (like firejail) automatically during their >>> launch. >> >> Could you expand on the use cases? Likewise, I would also like to hear about the intended use cases. > A non-security use case would be to run the binary (without > modification) with a different ELF interpreter (assuming this allows > to override binfmt_elf, but self-sandboxing would need that as well). > This would make it easier to use older or newer libcs for select > binaries on the system. Right now, one has to write wrappers for > that, and the explicit dynamic linker invocation is not completely > transparent to the application. I think this is a slightly contrived use case. Normally you would just use patchelf, or build the binary with a specific dynamic loader e.g. -Wl,--dynamic-linker=file. What is restricting the use case from modifying the binary or running under the new loader? Or to put it another way, what requires the interpreter selection to be fully dynamic? Why isn't the answer: Use ELF everywhere and specify the interpreter you actually want? Likewise if you know you want to one-off run a native binary in a sandbox or alternate loader then use a userspace tool to do that? Does the convenience gained justify the complexity we now have to explain to our users "Oh, and watch out for the xattr keywords that change how your application is started?" I'm doubtful. I haven't seen enough use cases here to justify a fully dynamic interpreter selection. It feels like a better use of our energy would be to make exec by the kernel and exec by the dynamic loader look as similar as possible so you can use one or the other without the application knowing the difference. My worry is that this is a new knob for something we have previously all expected to be a part of the binaries static definition. What impact will have on security validation? Is the binary running with the intended runtime? I assume that setting the xattr keyword requires write for the file in question, and that no capabilities mismatch means we could set the keyword but have less than write permissions on the file. There would also be a non-zero performance cost to this and it would be borne by all ELF/misc binaries at startup for what is a debugging feature. This assumes we extend binfmt_elf to look for the same xattr keyword to override the loader. This ignores the fact that the alternate loader also needs to have it's own ldconfig cache, implementation-dependent lookup paths etc, all of which have to be keyed off the xattr keyword specified dynamic loader. All of that is tractable though and can be done in userspace keyed from the selected dynamic loader. Buy why? Why not use a mount namespace and different loader e.g. lxc, docker, etc, or specify a loader that is a wrapper and does this for you? I'm not convinced this is a good idea, but I'm open to learning about more use cases. -- Cheers, Carlos.