[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1472198435-17622-1-git-send-email-JMax@mail.greenriver.edu>
Date: Fri, 26 Aug 2016 01:00:35 -0700
From: Josh Max <JMax@...l.greenriver.edu>
To: <James.Bottomley@...senPartnership.com>
CC: <viro@...iv.linux.org.uk>, <linux-fsdevel@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Josh Max <JMax@...l.greenriver.edu>
Subject: Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords
On Thu, 25 Aug 2016 16:15:40 +0000, James Bottomley wrote:
> 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?
Regarding sandboxing, my intent on this patch was to sandbox "trustworthy"
binaries (e.g. Apache, ssh, _insert_web_browser_here_, etc.) to reduce their
attack surface, rather than reduce the chances of a malicious process
compromising the system (without the need of maintaining a bunch of wrapper
scripts to launch said binaries under a sandbox). As such I'm using this patch
to sandbox Android's "app_process" service, as well as my personal web
browser. Of couse, it also has other benefits as well. For instance, an
observatory control software I use has a master daemon and several dome
control drivers, which are also native executables. Normally, you would need
to provide the correct driver as a parameter to the daemon, but with this patch
simply loading the driver also loads the daemon. I know of a few other
applications that do something similar to this that could benefit from xattr-based
interpreter selection.
Josh
Powered by blists - more mailing lists