All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@amacapital.net>
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>,
	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: Thu, 13 Dec 2012 18:33:27 -0800	[thread overview]
Message-ID: <876245jrbc.fsf@xmission.com> (raw)
In-Reply-To: <CALCETrXLLcUu8Rajjx7+3N_6j5E0T0CR1h=hD+gcc5_r4Umyqw@mail.gmail.com> (Andy Lutomirski's message of "Thu, 13 Dec 2012 15:21:24 -0800")


Andy thank you for your review.

Andy Lutomirski <luto@amacapital.net> writes:
> This is confusing enough that I can't immediately tell whether it's
> correct.  I think it's close but out of order.

Yeah.  That is the trick. Figuring out how to write that code so it is
correct and obvious.

I have added a comment at the top and removed the extra variable I was
adding.

The order except for verifying a user_ns->parent is valid by checking
for targ_ns == &init_user_ns doesn't make a difference.  Because
cred->user_ns can only be one of targ_ns or targ_ns->parent.

> Should this be transitive?

Yes.
>  I.e. suppose uid 1 owns a child of
> init_user_ns and uid 2 (mapped in the first ns as the identity) owns
> an inner ns.  Does uid 2 in the root ns have all caps inside?  I'd say
> no, but I don't have a great argument for that. 

I also say no.  It is more code and it doesn't fit my nice small
definition.  You have to be the owner and you have to be in the parent
of the target user namespace.  Being able to remember the rules in
your head is important.

> But uid 1 presumably
> does have caps because it could enter the parent with setns, then
> change uid, then enter the child.

Yes. uid 1 does have caps.

> How about (severely whitespace damaged):

You know that makes the termination condition a bit clearer.  But it
looses the nice place to put a comment when we loop again.  This loop
is just subtle enough that I want to preserve my comments.

I think I must have put -EPERM towards the end for the same reason to
make it clear that is the termination condition.

In practice I think it is important to have the cap_raised case first,
as that is the common case, and if we can be clear and still test that
case first it means the code will be faster.  With my reordering it is
obvious that nothing strange happens in the initial user namespace with
the owner test after the exit when we are the initial user namespace.

> int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
>                 int cap, int audit)
> {
>         struct user_namespace *here = targ_ns;
>
>         /* Walk up the namespace hierarchy until we find our own namespace. */
>         for (;;) {
>                 /* The owner of an ancestor namespace has all caps, if
> that owner is in the parent ns. */
>                 if (cred->user_ns == here->parent &&
> uid_eq(targ_ns->owner, cred->euid))
>                         return 0;

This would have needed a check that (here != &init_user_ns).  Because
the init_user_ns does not have a parent.

>                 /* Do we have the necessary capabilities? */
>                 if (here == cred->user_ns)
>                         return cap_raised(cred->cap_effective, cap) ?
> 0 : -EPERM;
>
>                 /* Have we tried all of the parent namespaces? */
>                 if (here == &init_user_ns)
>                         return -EPERM;
>                 else
>                         here = targ_ns->parent;
>         }
> }


  parent reply	other threads:[~2012-12-14  2:33 UTC|newest]

Thread overview: 54+ 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-11 21:17 ` Eric W. Biederman
     [not found] ` <87ip88uw4n.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 19:24   ` Andy Lutomirski
2012-12-13 19:24     ` Andy Lutomirski
     [not found]     ` <50CA2B55.5070402-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2012-12-13 22:01       ` Eric W. Biederman
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 23:21           ` Andy Lutomirski
     [not found]             ` <CALCETrXLLcUu8Rajjx7+3N_6j5E0T0CR1h=hD+gcc5_r4Umyqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  2:33               ` Eric W. Biederman
2012-12-14  2:33             ` Eric W. Biederman [this message]
     [not found]               ` <876245jrbc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14  2:36                 ` Andy Lutomirski
2012-12-14  2:36               ` Andy Lutomirski
2012-12-14  3:20                 ` [PATCH] " Eric W. Biederman
     [not found]                 ` <CALCETrXRYOh2tkwB+U9ZjA5BNZwscWsq1WGzjP3wUiOXQUXOQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  3:20                   ` Eric W. Biederman
     [not found]           ` <87zk1hshk7.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 22:43             ` [RFC][PATCH] " Linus Torvalds
2012-12-13 22:43               ` Linus Torvalds
     [not found]               ` <CA+55aFwXnFEFXbkwFPq9xt30xp2_6jfpBLd3E2bms79KKK=V1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-13 22:55                 ` Eric W. Biederman
2012-12-13 22:55               ` Eric W. Biederman
2012-12-13 23:21             ` Andy Lutomirski
2012-12-14  3:28             ` Serge E. Hallyn
2012-12-14  3:28           ` Serge E. Hallyn
     [not found]             ` <20121214032820.GA5115-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14  3:32               ` Eric W. Biederman
2012-12-14  3:32                 ` Eric W. Biederman
     [not found]                 ` <87bodxi9zw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 15:26                   ` Serge E. Hallyn
2012-12-14 15:26                     ` Serge E. Hallyn
2012-12-14 15:47                     ` Eric W. Biederman
     [not found]                       ` <87bodwd4aw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 16:15                         ` Serge E. Hallyn
2012-12-14 16:15                           ` Serge E. Hallyn
     [not found]                           ` <20121214161514.GA9962-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 18:12                             ` Eric W. Biederman
2012-12-14 18:12                               ` Eric W. Biederman
     [not found]                               ` <87r4ms5wpm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 18:43                                 ` Linus Torvalds
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
     [not found]                                   ` <CA+55aFw5CMf0-o=yDt2Rj-SYH4pfW1L9QbNb6uKHEdzAyYcvGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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 20:29                               ` Serge E. Hallyn
     [not found]                                 ` <20121214202921.GA11450-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 22:32                                   ` Eric W. Biederman
2012-12-14 22:32                                     ` Eric W. Biederman
2012-12-15  0:14                                     ` Serge E. Hallyn
     [not found]                                     ` <87bodww9hv.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15  0:14                                       ` Serge E. Hallyn
     [not found]                     ` <20121214152607.GA9266-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 15:47                       ` Eric W. Biederman
     [not found]         ` <87mwxhtxve.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 22:39           ` Eric W. Biederman
2012-12-13 23:02           ` [GIT PULL] user namespace and namespace infrastructure changes for 3.8 Andy Lutomirski
2012-12-13 23:02             ` Andy Lutomirski
     [not found]             ` <CALCETrWxXZ1OzZeH_SGeg1E16rssxBwg+hjG09N5dkqweVKeRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  4:11               ` Eric W. Biederman
2012-12-14  4:11                 ` Eric W. Biederman
     [not found]                 ` <87mwxhff2e.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14  5:34                   ` Andy Lutomirski
2012-12-14  5:34                     ` Andy Lutomirski
     [not found]                     ` <CALCETrXagfjy4o0_JCZpMfdocYK-MpOp3eH-tPZhgazvJAy-EQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14 17:48                       ` Eric W. Biederman
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=876245jrbc.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=serge@hallyn.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.