From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754272AbcHZVsW (ORCPT ); Fri, 26 Aug 2016 17:48:22 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:35470 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752806AbcHZVsV (ORCPT ); Fri, 26 Aug 2016 17:48:21 -0400 Message-ID: <1472247499.5189.96.camel@HansenPartnership.com> Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords From: James Bottomley To: "Carlos O'Donell" , Florian Weimer , Josh Max , viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 26 Aug 2016 17:38:19 -0400 In-Reply-To: <9906de02-1def-22f3-da7a-1040c65d09fd@redhat.com> References: <1471838494-29672-1-git-send-email-JMax@mail.greenriver.edu> <1472141735.3489.5.camel@HansenPartnership.com> <9856acd1-cab7-2691-1c89-279fbfe53e19@redhat.com> <9906de02-1def-22f3-da7a-1040c65d09fd@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-08-26 at 13:59 -0400, Carlos O'Donell wrote: > 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? So I'm now worried about the stacking case: if you're emulating the architecture for the binary, which is the traditional binfmt_misc use case, you can't use this xattr trick to override the elf interpreter because the sequence goes binfmt_misc -> qemu-user -> elf_interp meaning qemu-user has to know to look in the xattr. Doing patchelf fixes this case as well, so it sounds like the better solution. James