linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps.
Date: Sat, 15 Dec 2012 00:14:47 +0000	[thread overview]
Message-ID: <20121215001447.GD13659@mail.hallyn.com> (raw)
In-Reply-To: <87bodww9hv.fsf@xmission.com>

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> 
> >> A child user namespace having capabilities against processes in it's
> >> parent seems totally bizarre and pretty dangerous from a capabilities
> >> standpoint.
> >
> > How would it have them against its parent?
> 
> init_user_ns
>    userns a --- created by kuid 1

Now a mapping needs to be set up (by a task with CAP_SYS_ADMIN in
init_user_ns) which allows kuids 1 and 2 to be used by userns a.
Otherwise (if no mapping is set up) userns a only has the overlowuid.

Realistically only kuids over 100000 (let's say) would used.  i.e.
kuids 100,000-199,999 would map to container uids 0-99,999.

>      userns b -- created by kuid 2

Now a mapping needs to be set up (by a task with CAP_SYS_ADMIN in
userns a) which allows kuids 1 and 2 to be used by userns b.

If userns had been mapped with kuids 100,000-199,999 mapping to
uids 0-99999, then only kuids in that range could be mapped into
userns b.

>         process c in userns b with kuid 1
>
> Serge read the first permisison check in common_cap. 
> Think what happens in the above example.
> 
> For the rest I understand your concern.

Ok.  Then we can discuss my concern later (after the new year).

> Serge please read and look at the patches I have posted to fix
> the issues Andy found with the user namespace tree.  Especially
> the fix to commit_creds.

The setns fixes were IMO the most important - and interesting - ones :)

Thanks, Andy!

> After you have looked at the patches to fix the issues I will
> be happy to discuss things further with you.

Thanks,
-serge

  reply	other threads:[~2012-12-15  0:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 21:17 [GIT PULL] user namespace and namespace infrastructure changes for 3.8 Eric W. Biederman
2012-12-13 19:24 ` Andy Lutomirski
2012-12-13 22:01   ` Eric W. Biederman
2012-12-13 22:39     ` [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps Eric W. Biederman
2012-12-13 22:43       ` Linus Torvalds
2012-12-13 22:55         ` Eric W. Biederman
2012-12-13 23:21       ` Andy Lutomirski
2012-12-14  2:33         ` Eric W. Biederman
2012-12-14  2:36           ` Andy Lutomirski
2012-12-14  3:20             ` [PATCH] " Eric W. Biederman
2012-12-14  3:28       ` [RFC][PATCH] " Serge E. Hallyn
2012-12-14  3:32         ` Eric W. Biederman
2012-12-14 15:26           ` Serge E. Hallyn
2012-12-14 15:47             ` Eric W. Biederman
2012-12-14 16:15               ` Serge E. Hallyn
2012-12-14 18:12                 ` Eric W. Biederman
2012-12-14 18:43                   ` Linus Torvalds
2012-12-14 18:47                     ` Andy Lutomirski
2012-12-14 20:50                     ` Serge E. Hallyn
2012-12-14 21:43                     ` Eric W. Biederman
2012-12-14 20:29                   ` Serge E. Hallyn
2012-12-14 22:32                     ` Eric W. Biederman
2012-12-15  0:14                       ` Serge E. Hallyn [this message]
2012-12-13 23:02     ` [GIT PULL] user namespace and namespace infrastructure changes for 3.8 Andy Lutomirski
2012-12-14  4:11       ` Eric W. Biederman
2012-12-14  5:34         ` Andy Lutomirski
2012-12-14 17:48           ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121215001447.GD13659@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).