From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Andy Lutomirski <luto@amacapital.net>,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 3/4] userns: Add a more complete capability subset test to commit_creds
Date: Fri, 14 Dec 2012 16:11:38 -0800 [thread overview]
Message-ID: <87r4msrx6t.fsf@xmission.com> (raw)
In-Reply-To: <20121215000338.GC13659@mail.hallyn.com> (Serge E. Hallyn's message of "Sat, 15 Dec 2012 00:03:38 +0000")
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>>
>> When unsharing a user namespace we reduce our credentials to just what
>> can be done in that user namespace. This is a subset of the credentials
>> we previously had. Teach commit_creds to recognize this is a subset
>> of the credentials we have had before and don't clear the dumpability flag.
>>
>> This allows an unprivileged program to do:
>> unshare(CLONE_NEWUSER);
>> fd = open("/proc/self/uid_map", O_RDWR);
>>
>> Where previously opening the uid_map writable would fail because
>> the the task had been made non-dumpable.
>>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
>
>> ---
>> kernel/cred.c | 26 +++++++++++++++++++++++++-
>> 1 files changed, 25 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/cred.c b/kernel/cred.c
>> index 48cea3d..993a7ea41 100644
>> --- a/kernel/cred.c
>> +++ b/kernel/cred.c
>> @@ -455,6 +455,30 @@ error_put:
>> return ret;
>> }
>>
>
> Do you think we need to warn that this can only be used for
> commit_creds? (i.e. if someone tried ot use this in some
> other context, the 'creds are subset of target ns is a child
> of current_ns' assumption would be wrong)
This function should be a general test valid at any time.
Except that I forgot the bit of the test that asks is the original cred
the owner of the subset user namespace.
I will respin this patch.
As a small segway this property that unshare(CLONE_NEWUSER) results
in a subset of the capabilities a process already had is a very
important property to make it possible to reason about user namespaces.
Maintaining this property is the reason behind the choices I made
in fixing cap_capable.
>> +static bool cred_cap_issubset(const struct cred *set, const struct cred *subset)
>> +{
>> + const struct user_namespace *set_ns = set->user_ns;
>> + const struct user_namespace *subset_ns = subset->user_ns;
>> +
>> + /* If the two credentials are in the same user namespace see if
>> + * the capabilities of subset are a subset of set.
>> + */
>> + if (set_ns == subset_ns)
>> + return cap_issubset(subset->cap_permitted, set->cap_permitted);
>> +
>> + /* The credentials are in a different user namespaces
>
> This can only happen during setns and CLONE_NEWUSER right?
Right. This can only happen during setns, unshare(CLONE_NEWUSER),
and possibly during clone. Otherwise we are not changing the user
namespace. However for clarity and robustness I don't want the code
to rely on that.
>> + * therefore one is a subset of the other only if a set is an
>> + * ancestor of subset.
>> + */
>
>> + while (subset_ns != &init_user_ns) {
>> + if (set_ns == subset_ns->parent)
>> + return true;
>> + subset_ns = subset_ns->parent;
>> + }
>> +
>> + return false;
>> +}
>> +
>> /**
>> * commit_creds - Install new credentials upon the current task
>> * @new: The credentials to be assigned
>> @@ -493,7 +517,7 @@ int commit_creds(struct cred *new)
>> !gid_eq(old->egid, new->egid) ||
>> !uid_eq(old->fsuid, new->fsuid) ||
>> !gid_eq(old->fsgid, new->fsgid) ||
>> - !cap_issubset(new->cap_permitted, old->cap_permitted)) {
>> + !cred_cap_issubset(old, new)) {
>> if (task->mm)
>> set_dumpable(task->mm, suid_dumpable);
>> task->pdeath_signal = 0;
>> --
>> 1.7.5.4
next prev parent reply other threads:[~2012-12-15 0:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 22:01 [PATCH 0/4] user namespace fixes Eric W. Biederman
2012-12-14 22:01 ` Eric W. Biederman
2012-12-14 22:03 ` [PATCH 1/4] Fix cap_capable to only allow owners in the parent user namespace to have caps Eric W. Biederman
2012-12-14 22:03 ` [PATCH 2/4] userns: Require CAP_SYS_ADMIN for most uses of setns Eric W. Biederman
[not found] ` <87hanoxpdh.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 23:35 ` Serge E. Hallyn
2012-12-14 23:35 ` Serge E. Hallyn
2012-12-17 19:03 ` Andy Lutomirski
2012-12-17 19:03 ` Andy Lutomirski
2012-12-14 22:04 ` [PATCH 3/4] userns: Add a more complete capability subset test to commit_creds Eric W. Biederman
2012-12-15 0:03 ` Serge E. Hallyn
2012-12-15 0:11 ` Eric W. Biederman [this message]
[not found] ` <87r4msrx6t.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15 0:47 ` Serge E. Hallyn
2012-12-15 0:47 ` Serge E. Hallyn
[not found] ` <20121215004735.GA14295-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-15 0:48 ` Eric W. Biederman
2012-12-15 0:48 ` Eric W. Biederman
2012-12-15 2:06 ` Serge E. Hallyn
[not found] ` <87lid0rvh9.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15 2:06 ` Serge E. Hallyn
2012-12-17 19:08 ` Andy Lutomirski
2012-12-17 19:08 ` Andy Lutomirski
[not found] ` <20121215000338.GC13659-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-15 0:11 ` Eric W. Biederman
[not found] ` <87bodwxpcg.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15 0:03 ` Serge E. Hallyn
[not found] ` <87txroxpgq.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 22:03 ` [PATCH 1/4] Fix cap_capable to only allow owners in the parent user namespace to have caps Eric W. Biederman
2012-12-14 22:03 ` [PATCH 2/4] userns: Require CAP_SYS_ADMIN for most uses of setns Eric W. Biederman
2012-12-14 22:04 ` [PATCH 3/4] userns: Add a more complete capability subset test to commit_creds Eric W. Biederman
2012-12-14 22:05 ` [PATCH 4/4] userns: Fix typo in description of the limitation of userns_install Eric W. Biederman
2012-12-14 22:05 ` Eric W. Biederman
[not found] ` <876244xpbj.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 23:36 ` Serge E. Hallyn
2012-12-17 19:08 ` Andy Lutomirski
2012-12-17 19:08 ` Andy Lutomirski
2012-12-14 23:36 ` Serge E. Hallyn
2012-12-17 19:03 ` [PATCH 0/4] user namespace fixes Andy Lutomirski
2012-12-17 19:03 ` Andy Lutomirski
2012-12-17 21:01 ` Eric W. Biederman
[not found] ` <CALCETrX2Fa-DuM+wkgsij7oiJXzCD8W6Phkv-MjgCDg_Ma6CTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-17 21:01 ` 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=87r4msrx6t.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=containers@lists.linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=serge@hallyn.com \
/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.