From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754955AbcHYQRd (ORCPT ); Thu, 25 Aug 2016 12:17:33 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53832 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752559AbcHYQRa (ORCPT ); Thu, 25 Aug 2016 12:17:30 -0400 Message-ID: <1472141735.3489.5.camel@HansenPartnership.com> Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords From: James Bottomley To: Josh Max , viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 25 Aug 2016 12:15:35 -0400 In-Reply-To: <1471838494-29672-1-git-send-email-JMax@mail.greenriver.edu> References: <1471838494-29672-1-git-send-email-JMax@mail.greenriver.edu> 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 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? The patch set looks OK; the issue with extended attributes is lack of universal support on filesystems, but that may not be a problem because they're definitely supported on all the standard ones. I think the current F flag solves the foreign binary in chroot or container. Self sandboxing sounds reasonable, but if this is a security feature, doesn't having the label under the user. EAs mean that the confined binary can simply remove the label and unconfine itself? James