linux-kernel - Re: CLONE_NEWUSER documentation

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:	Mon, 06 Aug 2007 00:48:47 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Michael Kerrisk <mtk-manpages@....net>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Kirill Korotaev <dev@...nvz.org>,
	Herbert Poetzl <herbert@...hfloor.at>,
	Andrey Savochkin <saw@...ru>, Adrian Bunk <bunk@...sta.de>,
	Cedric Le Goater <clg@...ibm.com>,
	Chris Wright <chrisw@...s-sol.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Andrew Morgan <agm@...gle.com>
Subject: Re: CLONE_NEWUSER documentation

Michael Kerrisk <mtk-manpages@....net> writes:

>
> And again: is CLONE_NEWUSER (to be)implemented for unshare()?

They all should be.  Only the pid namespace (not yet merged) looks
like a problem for unshare.

> Thanks Eric.  I'm still not so clear though.  What is a user name space
> intended to be, and how is it to be used?
>
> Also, when will the implementation be complete?  If not by the 2.6.23 final
> release, it seems unfortunate to expose this flag to userspace, since
> further down the road, it will be difficult for userspace to tell whether
> the kernel below it really supports the flag or not.  Or am I missing
> something?

Currently the code depends on CONFIG_USER_NS it is CONFIG_EXPERIMENTAL
and defaulting to N.

So no one should be shipping a production with it enabled, hopefully
that is enough, to avoid problems.  I think the current implementation
is usable for some small subset of usable.

The basic idea is so that you have different mappings between uid and
gid values (i.e. /etc/passwd stuff) and struct user in the kernel.
Allowing the kernel to know two users with the same uid are distinct.

When you combined all of the namespaces (and when the are finished)
you have what is effective a chroot jail that looks like it has
the kernel all to itself despite other programs running.

Eric
-
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/