linux-kernel - Re: [PATCH review 12/16] userns: For /proc/self/{uid, gid}_map derive the lower userns from the struct file

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]

Message-ID: <20121119210153.GA11904@sergelap>
Date:	Mon, 19 Nov 2012 15:01:53 -0600
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linux Containers <containers@...ts.linux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH review 12/16] userns: For /proc/self/{uid, gid}_map
 derive the lower userns from the struct file

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Serge Hallyn <serge.hallyn@...onical.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@...ssion.com):
> >> From: "Eric W. Biederman" <ebiederm@...ssion.com>
> >> 
> >> To keep things sane in the context of file descriptor passing derive the
> >> user namespace that uids are mapped into from the opener of the file
> >> instead of from current.
> >> 
> >> When writing to the maps file the lower user namespace must always
> >> be the parent user namespace, or setting the mapping simply does
> >> not make sense.  Enforce that the opener of the file was in
> >> the parent user namespace or the user namespace whose mapping
> >> is being set.
> >
> > Is there a reasonable use case for writing from the ns whose mapping
> > is being set?  Are you expecting cases where the child opens the file
> > and passes it back to the parent to set the mappings?
> 
> Passing the open mappings file no.  Although by using seq_user_ns I do
> make certain the semantics are correct if the file descriptor is passed,
> but I did that on general principles.
> 
> I expect a process in the user namespace to be able to meaningfully set
> the mapping to some the current uid and the current gid.

Sorry, I think a word is missing there.  To be precise (bc I haven't
thought about this much before as it's not my target goal :) you're
saying if I'm uid 1000 gid 1000, I can create a new user namespace
and, from inside that new userns (where I'm first uid/gid -1) I can
map any uid+gid in the container to 1000 in the parent ns?  Or is there
something more?

It still seems to me no less flexible to require being in the parent
ns, so

> >> +	if ((seq_ns != ns) && (seq_ns != ns->parent))
> >> +		return -EPERM;

would become

> >> +	if (seq_ns != ns->parent)
> >> +		return -EPERM;

I also wonder if -EINVAL would be a more appropriate choice here.
We're trying to keep things sane, rather than saying "not allowed"
for its own sake.

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