public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <ikent@redhat.com>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: David Howells <dhowells@redhat.com>,
	Oleg Nesterov <onestero@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Benjamin Coddington <bcodding@redhat.com>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Jeff Layton <jeff.layton@primarydata.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [RFC PATCH 0/5] Second attempt at contained helper execution
Date: Wed, 14 Jan 2015 17:32:22 +0800	[thread overview]
Message-ID: <20150114092704.30252.60446.stgit@pluto.fritz.box> (raw)

This series is a further attempt to find how (or even an acceptable
way) to execute a usermode helper in a contained environment.

Being an attempt to find how to do this no testing has been done and
won't be until a suitable approach can be agreed on, if at all.

>From previous discussion seperation between the caller and the
execution environment is required for security reasons.

It was suggested that a thread be created for each mount and be used
as the basis for the execution environment. There are a number of
problems with this, not the least of which is scaling to a large
numbers of mounts, and there may not be a mount corresponding the the
needed callback which amounts to creating the process from the context
of the caller which we don't want to do.

But now, when a usermode helper is executed the root init namespace is
used and has proven to be adequate. So perhaps it will also be adequate
to use the same approach for contained execution by using the container
init namespace as the basis for the execution.

That's essentially all this series attempts to do.

There are other difficulties to tackle as well, such as how to decide
if contained helper execution is needed. For example, if a mount has
been propagated to a container or bound into the container tree (such
as with the --volume option of "docker run") the root init namespace
may need to be used and not the container namespace.

There's also the rather resource heavy method that is used here to
enter the target namespace which probably needs work but is out of
scope for this series if in fact this approach is even acceptable.

Comments please?

---

Ian Kent (5):
      nsproxy - refactor setns()
      kmod - rename call_usermodehelper() flags parameter
      kmod - teach call_usermodehelper() to use a namespace
      KEYS - rename call_usermodehelper_keys() flags parameter
      KEYS: exec request-key within the requesting task's init namespace


 include/linux/kmod.h        |   21 ++++++-
 include/linux/nsproxy.h     |    1 
 kernel/kmod.c               |  135 +++++++++++++++++++++++++++++++++++++++----
 kernel/nsproxy.c            |   21 ++++---
 security/keys/request_key.c |   51 ++++++++++++++--
 5 files changed, 201 insertions(+), 28 deletions(-)

--
Ian

             reply	other threads:[~2015-01-14  9:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14  9:32 Ian Kent [this message]
2015-01-14  9:32 ` [RFC PATCH 1/5] nsproxy - refactor setns() Ian Kent
2015-01-14  9:32 ` [RFC PATCH 2/5] kmod - rename call_usermodehelper() flags parameter Ian Kent
2015-01-14  9:32 ` [RFC PATCH 3/5] kmod - teach call_usermodehelper() to use a namespace Ian Kent
2015-01-15 16:45   ` Jeff Layton
2015-01-16  1:18     ` Ian Kent
2015-01-14  9:32 ` [RFC PATCH 4/5] KEYS - rename call_usermodehelper_keys() flags parameter Ian Kent
2015-01-14  9:32 ` [RFC PATCH 5/5] KEYS: exec request-key within the requesting task's init namespace Ian Kent
2015-01-14 21:55 ` [RFC PATCH 0/5] Second attempt at contained helper execution J. Bruce Fields
2015-01-14 22:10   ` J. Bruce Fields
2015-01-15  0:26     ` Ian Kent
2015-01-15 16:27       ` J. Bruce Fields
2015-01-16  1:01         ` Ian Kent
2015-01-16 15:25           ` J. Bruce Fields
2015-01-21  7:05             ` Ian Kent
2015-01-21 14:38               ` J. Bruce Fields
2015-01-22  1:28                 ` Ian Kent
2015-02-18 20:44                   ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150114092704.30252.60446.stgit@pluto.fritz.box \
    --to=ikent@redhat.com \
    --cc=bcodding@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jeff.layton@primarydata.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=onestero@redhat.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox