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:

quoted

On 08/25/2016 06:15 PM, James Bottomley wrote:

quoted

On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote:

quoted

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.

quoted

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