linux-kernel - [RFC PATCH 0/5] Second attempt at contained helper execution

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-next>] [day] [month] [year] [list]

Message-ID: <20150114092704.30252.60446.stgit@pluto.fritz.box>
Date:	Wed, 14 Jan 2015 17:32:22 +0800
From:	Ian Kent <ikent@...hat.com>
To:	Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	David Howells <dhowells@...hat.com>,
	Oleg Nesterov <onestero@...hat.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Benjamin Coddington <bcodding@...hat.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Jeff Layton <jeff.layton@...marydata.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: [RFC PATCH 0/5] Second attempt at contained helper execution

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/