linux-kernel - Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Aug 2016 17:38:19 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Carlos O'Donell <carlos@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        Josh Max <JMax@...l.greenriver.edu>, viro@...iv.linux.org.uk
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on
 xattr keywords

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