linux-kernel - Re: [PATCH 2/9] security: Make capabilities relative to the user namespace.

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: <20110223134352.GA926@mail.hallyn.com>
Date:	Wed, 23 Feb 2011 13:43:52 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	David Howells <dhowells@...hat.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	LSM <linux-security-module@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	James Morris <jmorris@...ei.org>,
	Kees Cook <kees.cook@...onical.com>,
	containers@...ts.linux-foundation.org,
	kernel list <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Michael Kerrisk <mtk.manpages@...il.com>, xemul@...allels.com
Subject: Re: [PATCH 2/9] security: Make capabilities relative to the user
 namespace.

Quoting David Howells (dhowells@...hat.com):
> David Howells <dhowells@...hat.com> wrote:
> 
> > >  	int (*capable) (struct task_struct *tsk, const struct cred *cred,
> > > -			int cap, int audit);
> > > +			struct user_namespace *ns, int cap, int audit);
> > 
> > Hmmm...  A chunk of the contents of the cred struct are user-namespaced.
> > Could you add the user_namespace pointer to the cred struct and thus avoid
> > passing it as an argument to other things.
> 
> Ah, no...  Ignore that, I think I see that you do need it.

Thanks for reviewing, David.

> > +int cap_capable(struct task_struct *tsk, const struct cred *cred,
> > +		struct user_namespace *targ_ns, int cap, int audit)
> >  {
> > -	return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> > +	for (;;) {
> > +		/* The creator of the user namespace has all caps. */
> > +		if (targ_ns != &init_user_ns && targ_ns->creator == cred->user)
> > +			return 0;
> 
> Why is that last comment so?  Why should the creating namespace sport all
> possible capabilities?  Do you have to have all capabilities available to you
> to be permitted create a new user namespace?

It's not the creating namespace, but the creating user, which has all caps.

So for instance, if uid 500 in init_user_ns creates a namespace, then:
  a. uid 500 in init_user_ns has all caps to the child user_ns, so it can
     kill the tasks in the userns, clean up, etc.
  b. uid X in any other child user_ns has no caps to the child user_ns.
  c. root in init_user_ns has whatever capabilities are in his pE to the
     child user_ns.  Again, this is so that the admin in any user_ns can
     clean up any messes made by users in his user_ns.

One of the goals of the user namespaces it to make it safe to allow
unprivileged users to create child user namespaces in which they have
targeted privilege.  Anything which happens in that child user namespace
should be:

  a. constrained to resources which the user can control anyway
  b. able to be cleaned up by the user
  c. (especially) able to be cleaned up by the privileged user in the
     parent user_ns.

> Also, would it be worth having a separate cap_ns_capable()?  Wouldn't most
> calls to cap_capable() only be checking the caps granted in the current user
> namespace?

Hm.  There is nsown_capable() which is targeted to current_userns(), but
that still needs to enable the caps for the privileged ancestors as
described above.

thanks,
-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/