linux-kernel - Re: [RFC PATCH] fs: 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:	Fri, 24 May 2013 09:44:38 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
CC:	Jeff Layton <jlayton@...hat.com>,
	Boaz Harrosh <bharrosh@...asas.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	<viro@...iv.linux.org.uk>, <serge.hallyn@...onical.com>,
	<lucas.demarchi@...fusion.mobi>, <rusty@...tcorp.com.au>,
	<linux-kernel@...r.kernel.org>, <oleg@...hat.com>,
	<linux-fsdevel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<devel@...nvz.org>
Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

23.05.2013 23:55, J. Bruce Fields пишет:
> On Thu, May 23, 2013 at 09:05:26AM -0400, Jeff Layton wrote:
>> On Thu, 23 May 2013 15:25:20 +0300
>>> I'm not familiar with nfsdcltrack but I would imagine it receives it's information from
>>> Kernel as a command line parameters.
>>>
>>> Would it not be the simplest approach to add a --chroot=/path/to/root optional
>>> parameter to nfsdcltrack so it should access an alternate DB relative to
>>> --chroot.
>>>
>>> This would address Eric's concern of not executing user-privileged executable
>>> from Kernel. I think
>>>
>>> Just my $0.017
>>> Boaz
>>>
>>
>> I think that sounds reasonable. Is it always the case
>> that /path/to/root is reachable from the "primary" namespace?
>
> I don't think we can assume that.
>

Yes, we can't. For example in case of different mount namespaces.

>> If not, you may need to do something more exotic there.
>
> We should be able to pass a file descriptor and then work relative to
> that.
>

We can't do this either.
Moreover, passing a file descriptor is something, that solves (?) completely different problem.
Imagine the following:
1) We have a host, based on, say RHEL6, which nfs-utils has doesn't have "/sbin/nfsdcltrack" and all.
2) And we have a container in it, based on, say, Fedora-19, which nfs-utils has this binary.

In case of starting NFSd in Fedora CT, we won't be able to execute the desired binary without root swapping.
Because we won't be able to even lookup it in the host file system.

So, as I said previously, the main problem here is not how to modify the userspace binary, but how to lookup and execute the right (!) one.
And I don't see, how we can do this (simple enough) without root swap.

-- 
Best regards,
Stanislav Kinsbursky
--
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/