From: "Serge E. Hallyn" <serge@hallyn.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
LKML <linux-kernel@vger.kernel.org>, Jann Horn <jann@thejh.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Seth Forshee <seth.forshee@canonical.com>,
LSM <linux-security-module@vger.kernel.org>,
"Andrew G. Morgan" <morgan@kernel.org>,
Kees Cook <keescook@chromium.org>,
Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Linux API <linux-api@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH RFC] user-namespaced file capabilities - now with more magic
Date: Thu, 19 May 2016 22:40:48 -0500 [thread overview]
Message-ID: <20160520034048.GA31216@mail.hallyn.com> (raw)
In-Reply-To: <1463691236.2465.74.camel@linux.vnet.ibm.com>
Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):
> On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote:
> > This patch introduces a new security.nscapability xattr. It
> > is mostly like security.capability, but also lists a 'rootid'.
> > This is 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.
> >
> > A privileged (cap_setfcap) process in the initial user ns may
> > set and read this xattr directly. However, its real intent is
> > to be used as a transparent fallback in user namespaces.
> >
> > Root in a user ns cannot be trusted to write security.capability
> > xattrs, because any 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.
> >
> > With this patch, when root in a user ns asks to write security.capability,
> > the kernel will transparently write a security.nscapability xattr
> > instead, filling in the kuid of the calling user's root uid. Subsequently,
> > any task executing the file which has the noted k_uid as its root uid,
> > or which is in a descendent user_ns of such a user_ns, will run the
> > file with capabilities.
> >
> > When reading the security.capability xattr from a non-init user_ns, a valid
> > security.nscapability will be shown if it exists. Such a task is not
> > allowed to read security.nscapability. This could be accomodated, however
>
> Add the word "directly" as "to read security.nscapability directly".
Updated in my git tree.
> > it requires the kernel to convert the kuid_t to a valid uid in the reader's
> > user_ns. So for now it's simply not supported.
>
> I really like the idea that the kernel transparently replaces
> nscapability for capability.
>
> > Only a single security.nscapability xattr may be written. This patch
> > could be expanded to allow a list of capabilities and rootids, however
> > I do not believe that to be a worthwhile use case.
>
> Ok
>
> > 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.
> >
> > Note - listxattr is not being handled here. So results of that can be
> > inconsistent with get/setxattr. Fixing that will require yet more
> > deceit in fs/xattr.c.
> >
> > Note2 - it may be less sneaky to hide all the magic behind the
> > security.nscapability xattr. So userspace would need to know to
> > use that xattr name when needed, but with the same format as
> > security.capability. The kuid_t rootid would be filled in by the
> > kernel. That's a middle ground between my last patch and this one.
>
> The less userspace needs to differentiate between running in a namespace
> and not, the better.
>
> Note3 - capability is currently protected by EVM, when enabled. Should
> ns_capability also be a protected xattr?
Hm - that would protect it from offline attacks, but allow the container
to update it, right? That sounds good.
> > Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
> > ---
> > fs/xattr.c | 18 ++-
> > include/linux/capability.h | 8 +-
> > include/uapi/linux/capability.h | 19 +++
> > include/uapi/linux/xattr.h | 3 +
> > security/commoncap.c | 253 ++++++++++++++++++++++++++++++++++++++--
> > 5 files changed, 291 insertions(+), 10 deletions(-)
> >
> > diff --git a/fs/xattr.c b/fs/xattr.c
> > index 4861322..5c0e7ae 100644
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -94,11 +94,26 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
> > {
> > struct inode *inode = dentry->d_inode;
> > int error = -EOPNOTSUPP;
> > + void *wvalue = NULL;
> > + size_t wsize = 0;
> > int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
> > XATTR_SECURITY_PREFIX_LEN);
> >
> > - if (issec)
> > + if (issec) {
> > inode->i_flags &= ~S_NOSEC;
> > + /* if root in a non-init user_ns tries to set
> > + * security.capability, write a security.nscapability
> > + * in its place */
> > + if (!strcmp(name, "security.capability") &&
> > + current_user_ns() != &init_user_ns) {
> > + cap_setxattr_make_nscap(dentry, value, size, &wvalue, &wsize);
> > + if (!wvalue)
> > + return -EPERM;
> > + value = wvalue;
> > + size = wsize;
> > + name = "security.nscapability";
> > + }
>
> The call to capable_wrt_inode_uidgid() is hidden behind
> cap_setxattr_make_nscap(). Does it make sense to call it here instead,
> before the security.capability test? This would lay the foundation for
> doing something similar for IMA.
Might make sense to move that. Though looking at it with fresh eyes I wonder
whether adding less code here at __vfs_setxattr_noperm(), i.e.
if (!cap_setxattr_makenscap(dentry, &value, &size, &name))
return -EPERM;
would be cleaner.
> (Will continue reviewing ...)
Awesome, thanks Mimi.
next prev parent reply other threads:[~2016-05-20 3:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 17:26 namespaced file capabilities serge.hallyn
2016-04-22 17:26 ` [PATCH 1/1] simplified security.nscapability xattr serge.hallyn
2016-04-26 19:46 ` Seth Forshee
2016-04-26 21:59 ` Kees Cook
2016-04-26 22:26 ` Serge E. Hallyn
2016-04-26 22:39 ` Kees Cook
2016-04-27 4:39 ` Serge E. Hallyn
2016-04-27 8:09 ` Jann Horn
2016-05-02 3:54 ` Serge E. Hallyn
2016-05-02 18:31 ` Michael Kerrisk (man-pages)
2016-05-02 21:31 ` Eric W. Biederman
[not found] ` <CALQRfL7mfpyudWs4Z8W5Zi8CTG-9O0OvrCnRU7pk0MXtsLBd0A@mail.gmail.com>
2016-05-03 4:50 ` Eric W. Biederman
2016-05-10 19:00 ` Serge E. Hallyn
2016-05-03 5:19 ` Serge E. Hallyn
2016-05-03 5:54 ` Eric W. Biederman
2016-05-03 14:25 ` Serge E. Hallyn
2016-05-10 19:03 ` Serge E. Hallyn
2016-05-07 23:10 ` Jann Horn
2016-05-11 21:02 ` Serge E. Hallyn
2016-05-16 21:15 ` Serge E. Hallyn
2016-05-16 21:48 ` Serge E. Hallyn
2016-05-18 21:57 ` [PATCH RFC] user-namespaced file capabilities - now with more magic Serge E. Hallyn
2016-05-19 20:53 ` Mimi Zohar
2016-05-20 3:40 ` Serge E. Hallyn [this message]
2016-05-20 11:19 ` Mimi Zohar
2016-05-20 18:28 ` Eric W. Biederman
2016-05-20 19:09 ` Mimi Zohar
2016-05-20 19:11 ` Eric W. Biederman
2016-05-20 19:26 ` Serge E. Hallyn
2016-05-20 19:42 ` Eric W. Biederman
2016-05-20 19:59 ` Serge E. Hallyn
2016-05-20 23:23 ` Mimi Zohar
2016-05-20 23:32 ` Serge E. Hallyn
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=20160520034048.GA31216@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=morgan@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=serge.hallyn@ubuntu.com \
--cc=seth.forshee@canonical.com \
--cc=zohar@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).