From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stanislav Kinsbursky Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced Date: Thu, 23 May 2013 14:35:53 +0400 Message-ID: <519DF109.9010309@parallels.com> References: <20130522072840.27720.85023.stgit@localhost.localdomain> <878v36ex6n.fsf@xmission.com> <519DCE5D.6070204@parallels.com> <87k3mq9fsu.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , , , , , , , , , To: "Eric W. Biederman" , Return-path: In-Reply-To: <87k3mq9fsu.fsf@xmission.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 23.05.2013 14:00, Eric W. Biederman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Stanislav Kinsbursky writes: > >> 22.05.2013 21:33, Eric W. Biederman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> Stanislav Kinsbursky writes: >>> >>>> Usermode helper executes all binaries in global "init" root contex= t. This >>>> doesn't allow to call a binary from other root context (for exampl= e in a >>>> container). >>>> Currently, both containerized NFS client and NFS server requires a= n ability to >>>> execute a binary in a container's root context. Root swap can be d= one in >>>> "init" callback, passed by UMH caller. >>>> But since we have 2 callers already (and more of them are expected= to appear >>>> in future) and because set_fs_root() in not exported, it looks rea= sonable to >>>> add one more generic UMH helper to generic fs code. >>>> Root path reference must be hold by the caller, since it will be p= ut on UMH >>>> thread exit. >>> >>> Awesome. With this patch as an uprivilieged user I get to pick whi= ch >>> binary the kernel will execute. At least if nfs and nfsd ever runs= in a >>> user namespace (something that looks like only matter of time). >>> >> >> Not really. Only by using a kernel module to call the UMH. >> And an unprivileged can't load a module as far a I know. >> I.e. NFSd, for example, will use unprivileged user's root to perform= this call. > > To help me understand the context which instances of call user mode > helper are you expecting to use this facility? > Ok. Here is how the NFSd uses UMH: UMH is used on NFSd service to start user-space client tracker daemon ("/sbin/nfsdcltarck"), which is used to store some per-client locks dat= a on persistent storage. >>> I think this is a seriously bad idea. >>> >>> Why can't we do this in userspace with setns as we do with the core= dump >>> helper? >>> >> >> Could you, please, clarify, how setns can help here? > > setns can change the mount namespace, and chroot can change to root > directory in the specified mount namespace. Essentially you can ente= r > into a containers complete context (pid, mnt, root, etc) comming from > the outside. > So, you are actually suggesting to move the binary start from the kerne= l to user-space. IOW, you are suggesting to do not using UMH at all. Am I right? I don't know the reasons, why it was done by using UMH and not in users= pace. Could you clarify this, Jeff? > For nfs and nfsd I believe everything is controlled by mounts. So th= e > alternate solution is to have a kernel thread for calling your user m= ode > helper processes that is created with plain old kernel_thread aka for= k > when we perform the controlling nfs mount, and have that thread be th= e > parent process for any containerized user mode helper calls. > Can't we just run into lack of credentials to execute the desired binar= y with this kernel_thread() approach? >>> I am missing a lot of context here and capturing the context of a >>> process at time time we mount the filesystem and reconstituing it i= n >>> call user mode helper seems like something we could do. >>> >>> This patch as it stands looks like it would compete for the honor o= f the >>> easiest kernel feature to exploit. >>> >> >> Hmmm... >> As far as I can see (maybe I'm missing something), there main securi= ty issue that could be here >> is allowing of using any passed root to swap to. > > Assuming that it is mounts that control this, and root in a user > namespace will be able to mount nfs. Then root in a user namespace w= ill > be able to cause any program to run as the global root by simply > performing the appropriate set of mounts, and triggering the user mod= e > helper. > Why you say "any program" in this case? There is no way to pass a program name into the kernel as far a I know. In case of NFSd the binary path is hard-coded in the kernel module. > Instant gaining of all capabilities and privilieges on the system giv= en > to a binary of your choice. > >> What about using the current root instead of passed one? I.e. taking= the root to swap to inside the UMH. >> Does this keeps the isolation on the same level? > > Passing the necessary information to the user mode helper so the user > mode helper can perform the swaps should be fine. That essentially i= s > what I was suggesting when I mentioned setns above. > Looks I'm missing something here. If you are not against of using the UMH itself, then there must be a wa= y to tell the UMH where it should lookup the binary (UHM thread's root is used to loo= kup for the path in existent implementation). And that's what I'm trying to implement. > Eric > --=20 Best regards, Stanislav Kinsbursky