From: ebiederm@xmission.com (Eric W. Biederman)
To: David Howells <dhowells@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Ian Kent <ikent@redhat.com>,
        Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "J. Bruce Fields" <bfields@fieldses.org>,
        Stanislav Kinsbursky <skinsbursky@parallels.com>,
        Trond Myklebust <trond.myklebust@primarydata.com>,
        Benjamin Coddington <bcodding@redhat.com>,
        Al Viro <viro@ZenIV.linux.org.uk>
References: <87y4qy7wci.fsf@x220.int.ebiederm.org>
	<20141125005255.4974.54193.stgit@pluto.fritz.box>
	<20141125010734.4974.85347.stgit@pluto.fritz.box>
	<20141125215248.GA7958@redhat.com> <20141125220637.GA10008@redhat.com>
	<1369.1417002382@warthog.procyon.org.uk>
Date: Wed, 26 Nov 2014 09:00:11 -0600
In-Reply-To: <1369.1417002382@warthog.procyon.org.uk> (David Howells's message
	of "Wed, 26 Nov 2014 11:46:22 +0000")
Message-ID: <87k32i0zyc.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper
Sender: linux-kernel-owner@vger.kernel.org

David Howells <dhowells@redhat.com> writes:

> Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> Ian if we were to merge this I believe you would win the award for
>> easiest path to a root shell.
>
> Is there any particular reason the upcalled program has to be run as root?
> Could the kernel not run it as something else - perhaps the caller's UID,GID
> or even something anonymous?
>
> Also, call_sbin_request_key() could be given a parameter to call something
> other than /sbin/request-key, and key_type::request_key could be used.

Fundamentally the upcall needs to happen with enough privileges to do
the job, and that means running in practice running as root in the
appropriate context.  If we didn't need to gain privileges we wouldn't
need an upcall.

In the code I was critisizing struct cred was not being changed because
of what I believe was an ignorance of what task->nsproxy was about and
is for.

It is straight forward to save off a for a kernel thread from the
process calling mount and make it responsible for the upcall and use
that as the parent for all of the containerized upcalls, and we could
easily run with that threads permissions.

We can't use the context of the triggering user but we instead need to
use the context of the mounter of the filesystem.  As otherwise the
triggering user can control what is /sbin/request-key and cause problems
that way.

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