public inbox for containers@lists.linux.dev
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Containers <containers@lists.linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Andrew G. Morgan" <morgan@kernel.org>
Subject: [GIT PULL] user namespace updates for v5.12-rc1
Date: Tue, 16 Feb 2021 11:14:06 -0600	[thread overview]
Message-ID: <m1o8gkrl41.fsf@fess.ebiederm.org> (raw)


Linus,

Please pull the userns-for-v5.12 branch from the git tree:

  git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git userns-for-v5.12

  HEAD: 95ebabde382c371572297915b104e55403674e73 capabilities: Don't allow writing ambiguous v3 file capabilities

There are several pieces of active development, but only a single change
made it through the gauntlet to be ready for v5.12.  That change is
tightening up the semantics of the v3 capabilities xattr.  It is just
short of being a bug-fix/security issue as no user space is known to
even generate the problem case.

A fix f2b00be48873 ("cap: fix conversions on getxattr") for v3 fscaps
has come in through the overlayfs tree for v5.11.  It touches different
functions so it should be conflict free.

Eric

commit 95ebabde382c371572297915b104e55403674e73
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 17 09:42:00 2020 -0600

    capabilities: Don't allow writing ambiguous v3 file capabilities
    
    The v3 file capabilities have a uid field that records the filesystem
    uid of the root user of the user namespace the file capabilities are
    valid in.
    
    When someone is silly enough to have the same underlying uid as the
    root uid of multiple nested containers a v3 filesystem capability can
    be ambiguous.
    
    In the spirit of don't do that then, forbid writing a v3 filesystem
    capability if it is ambiguous.
    
    Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
    Reviewed-by: Andrew G. Morgan <morgan@kernel.org>
    Reviewed-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 security/commoncap.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index bacc1111d871..74b9cc8cef34 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -481,7 +481,8 @@ int cap_convert_nscap(struct dentry *dentry, const void **ivalue, size_t size)
 	__u32 magic, nsmagic;
 	struct inode *inode = d_backing_inode(dentry);
 	struct user_namespace *task_ns = current_user_ns(),
-		*fs_ns = inode->i_sb->s_user_ns;
+		*fs_ns = inode->i_sb->s_user_ns,
+		*ancestor;
 	kuid_t rootid;
 	size_t newsize;
 
@@ -504,6 +505,15 @@ int cap_convert_nscap(struct dentry *dentry, const void **ivalue, size_t size)
 	if (nsrootid == -1)
 		return -EINVAL;
 
+	/*
+	 * Do not allow allow adding a v3 filesystem capability xattr
+	 * if the rootid field is ambiguous.
+	 */
+	for (ancestor = task_ns->parent; ancestor; ancestor = ancestor->parent) {
+		if (from_kuid(ancestor, rootid) == 0)
+			return -EINVAL;
+	}
+
 	newsize = sizeof(struct vfs_ns_cap_data);
 	nscap = kmalloc(newsize, GFP_ATOMIC);
 	if (!nscap)



_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

             reply	other threads:[~2021-02-16 17:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 17:14 Eric W. Biederman [this message]
2021-02-23  1:53 ` [GIT PULL] user namespace updates for v5.12-rc1 pr-tracker-bot

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=m1o8gkrl41.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox