[PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Janne Karhunen]

Current state of the kernel appears to be that there are more
than 1000 capable() calls and only handful are converted to
ns_capable(). Moreover, it probably does not make any sense
to convert most of these calls to be namespace aware due to
the nature of the physical resources they control, making
'capable()' the right question to ask. Yet, in order to be
able to build 'fully functional real device' like containers,
user namespaces sometimes need the access to real system
resources.

Thus, one potential candidate for enabling access to physical
resources from the user namespace would be to use namespaces
own CAP_SYS_RESOURCE as a magical token for making task
capabilities valid for init_ns.

Signed-off-by: Janne Karhunen <Janne.Karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 kernel/user_namespace.c |    8 ++++++++
 security/commoncap.c    |   18 ++++++++++++++++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index d8c30db..f7281fd 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -43,6 +43,14 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns)
 	key_put(cred->request_key_auth);
 	cred->request_key_auth = NULL;
 #endif
+
+	/* Since CAP_SYS_RESOURCE is the way out of user_ns, we start off having
+	 * it disabled.
+	 */
+	cap_lower (cred->cap_effective, CAP_SYS_RESOURCE);
+	cap_lower (cred->cap_permitted, CAP_SYS_RESOURCE);
+	cap_lower (cred->cap_inheritable, CAP_SYS_RESOURCE);
+
 	/* tgcred will be cleared in our caller bc CLONE_THREAD won't be set */
 	cred->user_ns = user_ns;
 }
diff --git a/security/commoncap.c b/security/commoncap.c
index c44b6fe..cdacb2d 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -83,9 +83,18 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
 	 * user namespace's parents.
 	 */
 	for (;;) {
-		/* Do we have the necessary capabilities? */
+		/* If we belong in this ns, do we have the capability? */
 		if (ns == cred->user_ns)
 			return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
+		else {
+			/* User_ns asking for rights in init_ns? */
+			if (ns == &init_user_ns) {
+				if (cap_raised(cred->cap_effective, CAP_SYS_RESOURCE))
+					return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
+				else
+					return -EPERM;
+			}
+		}
 
 		/* Have we tried all of the parent namespaces? */
 		if (ns == &init_user_ns)
@@ -481,7 +490,7 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
 	const struct cred *old = current_cred();
 	struct cred *new = bprm->cred;
 	bool effective, has_cap = false;
-	int ret;
+	int ret, has_res;
 	kuid_t root_uid;
 
 	effective = false;
@@ -501,6 +510,8 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
 			warn_setuid_and_fcaps_mixed(bprm->filename);
 			goto skip;
 		}
+		has_res = cap_raised(new->cap_permitted, CAP_SYS_RESOURCE);
+
 		/*
 		 * To support inheritance of root-permissions and suid-root
 		 * executables under compatibility mode, we override the
@@ -512,6 +523,9 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
 			/* pP' = (cap_bset & ~0) | (pI & ~0) */
 			new->cap_permitted = cap_combine(old->cap_bset,
 							 old->cap_inheritable);
+
+			if (!has_res && (old->user_ns != &init_user_ns))
+				cap_lower (new->cap_permitted, CAP_SYS_RESOURCE);
 		}
 		if (uid_eq(new->euid, root_uid))
 			effective = true;
-- 
1.7.9.5

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Janne Karhunen]

Hi,

To clarify that bit more - I'm experimenting with a system that has
absolute bare minimum init ns and everything sits in a container.
Given that, it would be nice if someone somewhere was actually able to
do something privileged...

Anyway, patch is just early proposal, better proposals welcome.


--
Janne

On Tue, May 7, 2013 at 11:01 AM, Janne Karhunen
<janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Current state of the kernel appears to be that there are more
> than 1000 capable() calls and only handful are converted to
> ns_capable(). Moreover, it probably does not make any sense
> to convert most of these calls to be namespace aware due to
> the nature of the physical resources they control, making
> 'capable()' the right question to ask. Yet, in order to be
> able to build 'fully functional real device' like containers,
> user namespaces sometimes need the access to real system
> resources.
>
> Thus, one potential candidate for enabling access to physical
> resources from the user namespace would be to use namespaces
> own CAP_SYS_RESOURCE as a magical token for making task
> capabilities valid for init_ns.
>
> Signed-off-by: Janne Karhunen <Janne.Karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  kernel/user_namespace.c |    8 ++++++++
>  security/commoncap.c    |   18 ++++++++++++++++--
>  2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index d8c30db..f7281fd 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -43,6 +43,14 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns)
>         key_put(cred->request_key_auth);
>         cred->request_key_auth = NULL;
>  #endif
> +
> +       /* Since CAP_SYS_RESOURCE is the way out of user_ns, we start off having
> +        * it disabled.
> +        */
> +       cap_lower (cred->cap_effective, CAP_SYS_RESOURCE);
> +       cap_lower (cred->cap_permitted, CAP_SYS_RESOURCE);
> +       cap_lower (cred->cap_inheritable, CAP_SYS_RESOURCE);
> +
>         /* tgcred will be cleared in our caller bc CLONE_THREAD won't be set */
>         cred->user_ns = user_ns;
>  }
> diff --git a/security/commoncap.c b/security/commoncap.c
> index c44b6fe..cdacb2d 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -83,9 +83,18 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
>          * user namespace's parents.
>          */
>         for (;;) {
> -               /* Do we have the necessary capabilities? */
> +               /* If we belong in this ns, do we have the capability? */
>                 if (ns == cred->user_ns)
>                         return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> +               else {
> +                       /* User_ns asking for rights in init_ns? */
> +                       if (ns == &init_user_ns) {
> +                               if (cap_raised(cred->cap_effective, CAP_SYS_RESOURCE))
> +                                       return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> +                               else
> +                                       return -EPERM;
> +                       }
> +               }
>
>                 /* Have we tried all of the parent namespaces? */
>                 if (ns == &init_user_ns)
> @@ -481,7 +490,7 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>         const struct cred *old = current_cred();
>         struct cred *new = bprm->cred;
>         bool effective, has_cap = false;
> -       int ret;
> +       int ret, has_res;
>         kuid_t root_uid;
>
>         effective = false;
> @@ -501,6 +510,8 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>                         warn_setuid_and_fcaps_mixed(bprm->filename);
>                         goto skip;
>                 }
> +               has_res = cap_raised(new->cap_permitted, CAP_SYS_RESOURCE);
> +
>                 /*
>                  * To support inheritance of root-permissions and suid-root
>                  * executables under compatibility mode, we override the
> @@ -512,6 +523,9 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>                         /* pP' = (cap_bset & ~0) | (pI & ~0) */
>                         new->cap_permitted = cap_combine(old->cap_bset,
>                                                          old->cap_inheritable);
> +
> +                       if (!has_res && (old->user_ns != &init_user_ns))
> +                               cap_lower (new->cap_permitted, CAP_SYS_RESOURCE);
>                 }
>                 if (uid_eq(new->euid, root_uid))
>                         effective = true;
> --
> 1.7.9.5
>

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Janne Karhunen]

On Tue, May 7, 2013 at 11:01 AM, Janne Karhunen
<janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> @@ -481,7 +490,7 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>         const struct cred *old = current_cred();
>         struct cred *new = bprm->cred;
>         bool effective, has_cap = false;
> -       int ret;
> +       int ret, has_res;
>         kuid_t root_uid;
>
>         effective = false;
> @@ -501,6 +510,8 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>                         warn_setuid_and_fcaps_mixed(bprm->filename);
>                         goto skip;
>                 }
> +               has_res = cap_raised(new->cap_permitted, CAP_SYS_RESOURCE);
> +
>                 /*
>                  * To support inheritance of root-permissions and suid-root
>                  * executables under compatibility mode, we override the
> @@ -512,6 +523,9 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
>                         /* pP' = (cap_bset & ~0) | (pI & ~0) */
>                         new->cap_permitted = cap_combine(old->cap_bset,
>                                                          old->cap_inheritable);
> +
> +                       if (!has_res && (old->user_ns != &init_user_ns))
> +                               cap_lower (new->cap_permitted, CAP_SYS_RESOURCE);
>                 }
>                 if (uid_eq(new->euid, root_uid))
>                         effective = true;

I am also seriously unhappy about this 'setuid compatibility mode'
here. It is highly surprising to have all caps elevated on uid/euid
root exec regardless of the executable setuid flags...


--
Janne

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Serge E. Hallyn]

Quoting Janne Karhunen (janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Tue, May 7, 2013 at 11:01 AM, Janne Karhunen
> <janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > @@ -481,7 +490,7 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
> >         const struct cred *old = current_cred();
> >         struct cred *new = bprm->cred;
> >         bool effective, has_cap = false;
> > -       int ret;
> > +       int ret, has_res;
> >         kuid_t root_uid;
> >
> >         effective = false;
> > @@ -501,6 +510,8 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
> >                         warn_setuid_and_fcaps_mixed(bprm->filename);
> >                         goto skip;
> >                 }
> > +               has_res = cap_raised(new->cap_permitted, CAP_SYS_RESOURCE);
> > +
> >                 /*
> >                  * To support inheritance of root-permissions and suid-root
> >                  * executables under compatibility mode, we override the
> > @@ -512,6 +523,9 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
> >                         /* pP' = (cap_bset & ~0) | (pI & ~0) */
> >                         new->cap_permitted = cap_combine(old->cap_bset,
> >                                                          old->cap_inheritable);
> > +
> > +                       if (!has_res && (old->user_ns != &init_user_ns))
> > +                               cap_lower (new->cap_permitted, CAP_SYS_RESOURCE);
> >                 }
> >                 if (uid_eq(new->euid, root_uid))
> >                         effective = true;
> 
> I am also seriously unhappy about this 'setuid compatibility mode'
> here. It is highly surprising to have all caps elevated on uid/euid
> root exec regardless of the executable setuid flags...

It shouldn't be surprising - it's all in capabilities(7), has nothing to
do with user namespaces, has been around a long time, and is configurable
with securebits.

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Serge E. Hallyn]

Quoting Janne Karhunen (janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> Current state of the kernel appears to be that there are more
> than 1000 capable() calls and only handful are converted to
> ns_capable(). Moreover, it probably does not make any sense
> to convert most of these calls to be namespace aware due to
> the nature of the physical resources they control, making
> 'capable()' the right question to ask. Yet, in order to be
> able to build 'fully functional real device' like containers,
> user namespaces sometimes need the access to real system
> resources.
> 
> Thus, one potential candidate for enabling access to physical
> resources from the user namespace would be to use namespaces
> own CAP_SYS_RESOURCE as a magical token for making task
> capabilities valid for init_ns.
> 
> Signed-off-by: Janne Karhunen <Janne.Karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Uh, I would say nack, and if you need this then a device
namespace allowing you to 'pass' devices similarly to how you
pass a physical nic to a child netns is a part of the answer.

Your goals are not 100% clear to me.  What is it about a user
namespace that you want?

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Janne Karhunen]

On Tue, May 7, 2013 at 8:10 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:

> Uh, I would say nack, and if you need this then a device
> namespace allowing you to 'pass' devices similarly to how you
> pass a physical nic to a child netns is a part of the answer.

Hmm, 'slight' issue is that it does not really exist and that ns
can not even be properly specified as functionality (we tried
that earlier didn't we - everyone had different opinion on what
that ns should really do).


> Your goals are not 100% clear to me.  What is it about a user
> namespace that you want?

I'm trying to experiment with a system that has init_ns size
of one tiny task and apart from that everything runs inside
containers. Because of this I need a way to elevate rights
of certain trusted applications inside user namespaces so
that they could operate against things requesting rights
from init ns.


-- 
Janne

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Eric W. Biederman]

Janne Karhunen <janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Tue, May 7, 2013 at 8:10 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
>
>> Uh, I would say nack, and if you need this then a device
>> namespace allowing you to 'pass' devices similarly to how you
>> pass a physical nic to a child netns is a part of the answer.
>
> Hmm, 'slight' issue is that it does not really exist and that ns
> can not even be properly specified as functionality (we tried
> that earlier didn't we - everyone had different opinion on what
> that ns should really do).

So far it appears that we don't need a device namespace.  As for most
things the usual DAC permissions apply.

The exceptions that I am aware of where we need something extra are
cases where the device abstraction is simply insufficient and needs
to be improved.

You can pass real network devices between network namespaces.

>> Your goals are not 100% clear to me.  What is it about a user
>> namespace that you want?
>
> I'm trying to experiment with a system that has init_ns size
> of one tiny task and apart from that everything runs inside
> containers. Because of this I need a way to elevate rights
> of certain trusted applications inside user namespaces so
> that they could operate against things requesting rights
> from init ns.

It will never be acceptable for tasks in a user namespace to have
any rights outside of that user namespace.  Elevating rights is the
wrong model.

The model very much needs to be how do we make a device safe for use by
an unprivielged user.

Most devices you can allow access to users in a user namespace with a
simple chmod.

You will also have the problem of how do you mount filesystems.  Except
for tmpfs I don't think there are any writable filesystems mountable in
a mount namespace created by a user namespace.

Your goal does sound interesting however.

Eric

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Janne Karhunen]

On Tue, May 7, 2013 at 9:38 PM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:

> So far it appears that we don't need a device namespace.  As for most
> things the usual DAC permissions apply.

Serge, please note ;)


> The exceptions that I am aware of where we need something extra are
> cases where the device abstraction is simply insufficient and needs
> to be improved.
>
> You can pass real network devices between network namespaces.

Have you considered passing things like frame buffer, input subsystem
and/or modem(s)?


>>> Your goals are not 100% clear to me.  What is it about a user
>>> namespace that you want?
>>
>> I'm trying to experiment with a system that has init_ns size
>> of one tiny task and apart from that everything runs inside
>> containers. Because of this I need a way to elevate rights
>> of certain trusted applications inside user namespaces so
>> that they could operate against things requesting rights
>> from init ns.
>
> It will never be acceptable for tasks in a user namespace to have
> any rights outside of that user namespace.  Elevating rights is the
> wrong model.

As ideal goal you're fully right, but given that init_ns size is almost
non-existent do you think that it is realistic to expect that no one
ever needs elevated rights within the container?

So all in all, I'm trying to make things work for real and complete
Linux systems since if this is done right, I think it is possible that
in the long run distributions start to default to running everything
inside container. If there is no privilege escalation possibility at all,
you just ruled out a huge bunch of existing configuration/etc tools
and for the next 5+ years, devices and kernel features.

For me containers are not so much a security feature but rather
a functional one.


> The model very much needs to be how do we make a device safe for use by
> an unprivielged user.
>
> Most devices you can allow access to users in a user namespace with a
> simple chmod.
>
> You will also have the problem of how do you mount filesystems.  Except
> for tmpfs I don't think there are any writable filesystems mountable in
> a mount namespace created by a user namespace.
>
> Your goal does sound interesting however.

Great to hear you agreed on the goal.


--
Janne

Re: [PATCH] Use CAP_SYS_RESOURCE as magic for escaping user namespaces.

[Serge E. Hallyn]

Quoting Janne Karhunen (janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Tue, May 7, 2013 at 9:38 PM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> 
> > So far it appears that we don't need a device namespace.  As for most
> > things the usual DAC permissions apply.
> 
> Serge, please note ;)

?

Here are some possibilities regarding devices:

1. ptys are already namespaced in their own way
2. loop is not namespaced, but easily could be.  The question is how to
   trigger a new namespace for them.  Maybe a loopfs with newinstance
   option :)
3. c 4 1 (/dev/tty1).  Right now containers handle this purely through
   obfuscation at the filename level, symlinking /dev/tty1 to a pty.
   We could namespace tasks at a tty level, so that c 4 1 either points
   to a provided open fd, or to nothing, in the new namespace.
4. Video cards could be handled by introducing virtual devices to
   replace the physical ones, OR they could be handled by passing the
   physical video card to a different X namespace (X being user, device,
   or something else).  Both have in the past been mentioned by Eric,
   and they're not mutually exclusive.

So, I object to a blanket "this capability changes the meaning of all
your other capabilities with respect to the hardware."  However, perhaps
we could do something like "pass this device to that user namespace, so
that any capabilities he has toward his user namespace will be allowed
against that device."

> > The exceptions that I am aware of where we need something extra are
> > cases where the device abstraction is simply insufficient and needs
> > to be improved.
> >
> > You can pass real network devices between network namespaces.
> 
> Have you considered passing things like frame buffer, input subsystem
> and/or modem(s)?

We have, but I'm not sure we've discussed (though I'm sure we've all
thought about) just passing straight to a user namespace.

-serge