linux-kernel - Re: [RFC PATCH 3/4] kmod - add call_usermodehelper

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, 26 Nov 2014 17:57:20 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	David Howells <dhowells@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Ian Kent <ikent@...hat.com>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stanislav Kinsbursky <skinsbursky@...allels.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Benjamin Coddington <bcodding@...hat.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper

On Wed, Nov 26, 2014 at 09:00:11AM -0600, Eric W. Biederman wrote:
> David Howells <dhowells@...hat.com> writes:
> 
> > Eric W. Biederman <ebiederm@...ssion.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.

That makes sense to me.  There are three cases I think we care about:

	- client idmapper upcall: translates between on-the-wire
	  "user@...ain" names and local uid's/gid's.  The results may be
	  cached and used by other users, and you certainly don't want
	  the user who happened to trigger the upcall by doing a "ls" to
	  poison the cache with weird values.

	- server-side state recovery call: used to record some
	  information about which clients hold active state.  There's no
	  "mount" on the server side, but "root in the appropriate
	  context" still sounds right--we probably want to save the
	  context of whoever started the server.  One extra thread per
	  server would certainly be no big deal, so if that's how we
	  need to save the context, fine.

	- client request-key call: this isn't actually implemented yet
	  and I don't feel like I understand it.

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