From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
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: Tue, 29 Nov 2016 15:29:52 -0600 [thread overview]
Message-ID: <20161129212952.GA10816@mail.hallyn.com> (raw)
In-Reply-To: <0d1a7bc4-2e9c-73ba-11fb-f233e790b3a6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On 11/25/2016 06:50 PM, Serge E. Hallyn wrote:
> > On Fri, Nov 25, 2016 at 09:33:50AM +0100, Michael Kerrisk (man-pages) wrote:
> >> Hi Serge,
> >>
> >> On 11/24/2016 11:52 PM, Serge E. Hallyn wrote:
> >>> Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> >>
> >> [...]
> >>
> >>>> Could we have a man-pages patch for this feature? Presumably for
> >>>> user_namespaces(7) or capabilities(7).
> >>>
> >>> capabilities.7 doesn't actually mention anything about user namespaces
> >>> right now.
> >>
> >> True. There's really just this:
> >>
> >> Interaction with user namespaces
> >> For a discussion of the interaction of capabilities and user
> >> namespaces, see user_namespaces(7).
> >>
> >>> I'll come up with a patch for both I think. Do you have a
> >>> deadline for a new release coming up?
> >>
> >> No deadlines as such. The last couple of years, as a sort of
> >> experiment, I've fallen into the same release cycle as the kernel
> >> (typically making a release in the week or so after the kernel release),
> >> and I am even using a similar numbering scheme. Ideally, the man-pages
> >> patch would go into the release that corresponds to the kernel release
> >> that makes the change.
> >
> > Cool - I'll write something up in the next few weeks.
>
> Obviously, the sooner you write it, the sooner others may read--and
> perhaps test--it.
Hi,
first draft
https://git.kernel.org/cgit/linux/kernel/git/sergeh/man-pages.git/commit/?h=2016-11-29/nscaps
>From 62578b7cb2e0cbb100d1b29000de5657e9d998c4 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
Date: Tue, 29 Nov 2016 15:25:37 -0600
Subject: [PATCH 1/1] Describe the new namespaced file capabilities.
---
man7/user_namespaces.7 | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/man7/user_namespaces.7 b/man7/user_namespaces.7
index 0c99df0..b1dd027 100644
--- a/man7/user_namespaces.7
+++ b/man7/user_namespaces.7
@@ -208,6 +208,41 @@ further removed descendant user namespaces as well.
.\"
.\" ============================================================
.\"
+.SS File capabilities in user namespaces
+Until v4.9, writing file capabilities required the writer to possess
+.BR CAP_SETFCAP
+targeted at the initial user namespace. In v4.10 a new version (v3) of the
+file capability extended attribute was introduced, which targets the
+capabilities at a namespace root userid. This means that a task executing the
+file will receive elevated privilege only if it is running in a namespace whose
+root is mapped to the specified target uid. If a task does not have
+.BR CAP_SETFCAP
+toward the user namespace which owns the filesystem hosting the file, then it
+can only write file capabilities targeted at uids mapped in the task's own
+namespace.
+
+As a detailed example, assume a user namespace where uid 0 is mapped to host
+uid 100000. Root in the container writes a file capability. If the file
+capability xattr is v2, then a v3 capability xattr targeted to 100000 will be
+written.
+
+If instead a v3 capability xattr is written, then the kernel will verify that
+the writer is privileged with
+.BR CAP_SETFCAP
+over its own namespace and that the file owner's uid and gid are mapped into
+the current task's namespace.
+
+The capability target uid which is written to disk is mapped into the
+filesystem's user namespace. Therefore, in the above example, if uid 0 in the
+namespace (100000 on the host) mounted the filesystem, the target uid value
+actually written will be converted back to 0 (the mapped value for host uid
+100000). In this case the mount will be treated as foreign for any tasks in
+the initial user namespace, so that the file capability (as well as setuid and
+setgid bits) will be ignored, preventing a leak of privilege.
+
+.\"
+.\" ============================================================
+.\"
.SS Effect of capabilities within a user namespace
Having a capability inside a user namespace
permits a process to perform operations (that require privilege)
--
2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
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: Tue, 29 Nov 2016 15:29:52 -0600 [thread overview]
Message-ID: <20161129212952.GA10816@mail.hallyn.com> (raw)
In-Reply-To: <0d1a7bc4-2e9c-73ba-11fb-f233e790b3a6@gmail.com>
Quoting Michael Kerrisk (man-pages) (mtk.manpages@gmail.com):
> On 11/25/2016 06:50 PM, Serge E. Hallyn wrote:
> > On Fri, Nov 25, 2016 at 09:33:50AM +0100, Michael Kerrisk (man-pages) wrote:
> >> Hi Serge,
> >>
> >> On 11/24/2016 11:52 PM, Serge E. Hallyn wrote:
> >>> Quoting Michael Kerrisk (man-pages) (mtk.manpages@gmail.com):
> >>
> >> [...]
> >>
> >>>> Could we have a man-pages patch for this feature? Presumably for
> >>>> user_namespaces(7) or capabilities(7).
> >>>
> >>> capabilities.7 doesn't actually mention anything about user namespaces
> >>> right now.
> >>
> >> True. There's really just this:
> >>
> >> Interaction with user namespaces
> >> For a discussion of the interaction of capabilities and user
> >> namespaces, see user_namespaces(7).
> >>
> >>> I'll come up with a patch for both I think. Do you have a
> >>> deadline for a new release coming up?
> >>
> >> No deadlines as such. The last couple of years, as a sort of
> >> experiment, I've fallen into the same release cycle as the kernel
> >> (typically making a release in the week or so after the kernel release),
> >> and I am even using a similar numbering scheme. Ideally, the man-pages
> >> patch would go into the release that corresponds to the kernel release
> >> that makes the change.
> >
> > Cool - I'll write something up in the next few weeks.
>
> Obviously, the sooner you write it, the sooner others may read--and
> perhaps test--it.
Hi,
first draft
https://git.kernel.org/cgit/linux/kernel/git/sergeh/man-pages.git/commit/?h=2016-11-29/nscaps
>From 62578b7cb2e0cbb100d1b29000de5657e9d998c4 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge@hallyn.com>
Date: Tue, 29 Nov 2016 15:25:37 -0600
Subject: [PATCH 1/1] Describe the new namespaced file capabilities.
---
man7/user_namespaces.7 | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/man7/user_namespaces.7 b/man7/user_namespaces.7
index 0c99df0..b1dd027 100644
--- a/man7/user_namespaces.7
+++ b/man7/user_namespaces.7
@@ -208,6 +208,41 @@ further removed descendant user namespaces as well.
.\"
.\" ============================================================
.\"
+.SS File capabilities in user namespaces
+Until v4.9, writing file capabilities required the writer to possess
+.BR CAP_SETFCAP
+targeted at the initial user namespace. In v4.10 a new version (v3) of the
+file capability extended attribute was introduced, which targets the
+capabilities at a namespace root userid. This means that a task executing the
+file will receive elevated privilege only if it is running in a namespace whose
+root is mapped to the specified target uid. If a task does not have
+.BR CAP_SETFCAP
+toward the user namespace which owns the filesystem hosting the file, then it
+can only write file capabilities targeted at uids mapped in the task's own
+namespace.
+
+As a detailed example, assume a user namespace where uid 0 is mapped to host
+uid 100000. Root in the container writes a file capability. If the file
+capability xattr is v2, then a v3 capability xattr targeted to 100000 will be
+written.
+
+If instead a v3 capability xattr is written, then the kernel will verify that
+the writer is privileged with
+.BR CAP_SETFCAP
+over its own namespace and that the file owner's uid and gid are mapped into
+the current task's namespace.
+
+The capability target uid which is written to disk is mapped into the
+filesystem's user namespace. Therefore, in the above example, if uid 0 in the
+namespace (100000 on the host) mounted the filesystem, the target uid value
+actually written will be converted back to 0 (the mapped value for host uid
+100000). In this case the mount will be treated as foreign for any tasks in
+the initial user namespace, so that the file capability (as well as setuid and
+setgid bits) will be ignored, preventing a leak of privilege.
+
+.\"
+.\" ============================================================
+.\"
.SS Effect of capabilities within a user namespace
Having a capability inside a user namespace
permits a process to perform operations (that require privilege)
--
2.7.4
next prev parent reply other threads:[~2016-11-29 21:29 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 [this message]
2016-11-29 21:29 ` Serge E. Hallyn
2016-12-08 4:43 ` Eric W. Biederman
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=20161129212952.GA10816@mail.hallyn.com \
--to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@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.