linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2015 16:55:25 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Ian Kent <ikent@...hat.com>
Cc:	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Oleg Nesterov <onestero@...hat.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	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: Re: [RFC PATCH 0/5] Second attempt at contained helper execution

On Wed, Jan 14, 2015 at 05:32:22PM +0800, Ian Kent wrote:
> 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

Remind me what example you're thinking of here?

--b.

> 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/