linux-kernel - Re: call_usermodehelper in containers

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:	Tue, 12 Nov 2013 06:12:01 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org,
	Stanislav Kinsbursky <skinsbursky@...allels.com>,
	devel@...nvz.org, ebiederm@...ssion.com, oleg@...hat.com,
	bfields@...ldses.org, bharrosh@...asas.com
Subject: Re: call_usermodehelper in containers

On Mon, 11 Nov 2013 16:47:03 -0800
Greg KH <gregkh@...uxfoundation.org> wrote:

> On Mon, Nov 11, 2013 at 07:18:25AM -0500, Jeff Layton wrote:
> > We have a bit of a problem wrt to upcalls that use call_usermodehelper
> > with containers and I'd like to bring this to some sort of resolution...
> > 
> > A particularly problematic case (though there are others) is the
> > nfsdcltrack upcall. It basically uses call_usermodehelper to run a
> > program in userland to track some information on stable storage for
> > nfsd.
> 
> I thought the discussion at the kernel summit about this issue was:
> 	- don't do this.
> 	- don't do it.
> 	- if you really need to do this, fix nfsd
> 

Sorry, I couldn't make the kernel summit so I missed that discussion. I
guess LWN didn't cover it?

In any case, I guess then that we'll either have to come up with some
way to fix nfsd here, or simply ensure that nfsd can never be started
unless root in the container has a full set of a full set of
capabilities.

One sort of Rube Goldberg possibility to fix nfsd is:

- when we start nfsd in a container, fork off an extra kernel thread
  that just sits idle. That thread would need to be a descendant of the
  userland process that started nfsd, so we'd need to create it with
  kernel_thread().

- Have the kernel just start up the UMH program in the init_ns mount
  namespace as it currently does, but also pass the pid of the idle
  kernel thread to the UMH upcall.

- The program will then use /proc/<pid>/root and /proc/<pid>/ns/* to set
  itself up for doing things properly.

Note that with this mechanism we can't actually run a different binary
per container, but that's probably fine for most purposes.

-- 
Jeff Layton <jlayton@...hat.com>
--
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/