From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754006AbcHZOzz (ORCPT ); Fri, 26 Aug 2016 10:55:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47106 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752013AbcHZOzx (ORCPT ); Fri, 26 Aug 2016 10:55:53 -0400 Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords To: 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> Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "Carlos O'Donell" From: Florian Weimer Message-ID: <9856acd1-cab7-2691-1c89-279fbfe53e19@redhat.com> Date: Fri, 26 Aug 2016 16:55:50 +0200 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: <1472141735.3489.5.camel@HansenPartnership.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 26 Aug 2016 14:55:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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. Florian