From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
Cc: Seth Forshee
<seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic
Date: Thu, 08 Dec 2016 17:43:09 +1300 [thread overview]
Message-ID: <87inqvav4y.fsf@xmission.com> (raw)
In-Reply-To: <20161119151739.GA16398-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> (Serge E. Hallyn's message of "Sat, 19 Nov 2016 09:17:39 -0600")
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> Root in a user ns cannot be trusted to write a traditional
> security.capability xattr. If it were allowed to do so, then any
> unprivileged user on the host could map his own uid to root in a
> namespace, write the xattr, and execute the file with privilege on the
> host.
>
> This patch introduces v3 of the security.capability xattr. It builds a
> vfs_ns_cap_data struct by appending a uid_t rootid to struct
> vfs_cap_data. This is the absolute uid_t (i.e. the uid_t in
> init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> the file capabilities may take effect.
>
> When a task in a user ns (which is privileged with CAP_SETFCAP toward
> that user_ns) asks to write v2 security.capability, the kernel will
> transparently rewrite the xattr as a v3 with the appropriate rootid.
> Subsequently, any task executing the file which has the noted kuid as
> its root uid, or which is in a descendent user_ns of such a user_ns,
> will run the file with capabilities.
>
> If a task writes a v3 security.capability, then it can provide a
> uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> for the xattr. The kernel will translate that to the absolute uid, and
> write that to disk. After this, a task in the writer's namespace will
> not be able to use those capabilities, but a task in a namespace where
> the given uid is root will.
>
> Only a single security.capability xattr may be written. A task may
> overwrite the existing one so long as it was written by a user mapped
> into his own user_ns over which he has CAP_SETFCAP.
>
> This allows a simple setxattr to work, allows tar/untar to work, and
> allows us to tar in one namespace and untar in another while preserving
> the capability, without risking leaking privilege into a parent
> namespace.
Any chance of a singed-off-by?
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Seth Forshee <seth.forshee@canonical.com>,
lkml <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org
Subject: Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic
Date: Thu, 08 Dec 2016 17:43:09 +1300 [thread overview]
Message-ID: <87inqvav4y.fsf@xmission.com> (raw)
In-Reply-To: <20161119151739.GA16398@mail.hallyn.com> (Serge E. Hallyn's message of "Sat, 19 Nov 2016 09:17:39 -0600")
"Serge E. Hallyn" <serge@hallyn.com> writes:
> Root in a user ns cannot be trusted to write a traditional
> security.capability xattr. If it were allowed to do so, then any
> unprivileged user on the host could map his own uid to root in a
> namespace, write the xattr, and execute the file with privilege on the
> host.
>
> This patch introduces v3 of the security.capability xattr. It builds a
> vfs_ns_cap_data struct by appending a uid_t rootid to struct
> vfs_cap_data. This is the absolute uid_t (i.e. the uid_t in
> init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> the file capabilities may take effect.
>
> When a task in a user ns (which is privileged with CAP_SETFCAP toward
> that user_ns) asks to write v2 security.capability, the kernel will
> transparently rewrite the xattr as a v3 with the appropriate rootid.
> Subsequently, any task executing the file which has the noted kuid as
> its root uid, or which is in a descendent user_ns of such a user_ns,
> will run the file with capabilities.
>
> If a task writes a v3 security.capability, then it can provide a
> uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> for the xattr. The kernel will translate that to the absolute uid, and
> write that to disk. After this, a task in the writer's namespace will
> not be able to use those capabilities, but a task in a namespace where
> the given uid is root will.
>
> Only a single security.capability xattr may be written. A task may
> overwrite the existing one so long as it was written by a user mapped
> into his own user_ns over which he has CAP_SETFCAP.
>
> This allows a simple setxattr to work, allows tar/untar to work, and
> allows us to tar in one namespace and untar in another while preserving
> the capability, without risking leaking privilege into a parent
> namespace.
Any chance of a singed-off-by?
Eric
next prev parent reply other threads:[~2016-12-08 4:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-19 15:17 [PATCH RFC] user-namespaced file capabilities - now with even more magic Serge E. Hallyn
[not found] ` <20161119151739.GA16398-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-11-23 23:01 ` Eric W. Biederman
2016-11-23 23:01 ` Eric W. Biederman
2016-11-24 8:15 ` Michael Kerrisk (man-pages)
2016-11-24 8:15 ` Michael Kerrisk (man-pages)
[not found] ` <8acb3b53-d5eb-0524-2c57-31fcb7e736d9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-24 22:52 ` Serge E. Hallyn
2016-11-24 22:52 ` Serge E. Hallyn
2016-11-25 8:33 ` Michael Kerrisk (man-pages)
[not found] ` <d2160ca5-12e5-0be7-ade7-c4ee63e1df32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 17:50 ` Serge E. Hallyn
2016-11-25 17:50 ` Serge E. Hallyn
[not found] ` <20161125175009.GA326-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-11-25 20:43 ` Michael Kerrisk (man-pages)
2016-11-25 20:43 ` Michael Kerrisk (man-pages)
[not found] ` <0d1a7bc4-2e9c-73ba-11fb-f233e790b3a6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-29 21:29 ` Serge E. Hallyn
2016-11-29 21:29 ` Serge E. Hallyn
2016-12-08 4:43 ` Eric W. Biederman [this message]
2016-12-08 4:43 ` Eric W. Biederman
[not found] ` <87inqvav4y.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2016-12-08 4:56 ` Serge E. Hallyn
2016-12-08 4:56 ` Serge E. Hallyn
[not found] ` <20161208045640.GA433-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-12-08 5:13 ` Eric W. Biederman
2016-12-08 5:13 ` Eric W. Biederman
2016-12-09 8:03 ` Eric W. Biederman
2016-12-09 8:03 ` Eric W. Biederman
[not found] ` <87oa0ljzq0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2016-12-09 13:42 ` Serge E. Hallyn
2016-12-09 13:42 ` Serge E. Hallyn
[not found] ` <20161209134242.GA20577-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-12-09 21:39 ` Eric W. Biederman
2016-12-09 21:39 ` Eric W. Biederman
[not found] ` <878trokcjc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2016-12-09 23:29 ` Eric W. Biederman
2016-12-09 23:29 ` 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=87inqvav4y.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
--cc=seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.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.