mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Stefan Berger <StefanBergerstefanb@linux.vnet.ibm.com>
Cc: ebiederm@xmission.com, containers@lists.linux-foundation.org,
	lkp@01.org, linux-kernel@vger.kernel.org,
	zohar@linux.vnet.ibm.com, tycho@docker.com, serge@hallyn.com,
	James.Bottomley@HansenPartnership.com, vgoyal@redhat.com,
	christian.brauner@mailbox.org, amir73il@gmail.com,
	linux-security-module@vger.kernel.org, casey@schaufler-ca.com,
	Stefan Berger <stefanb@linux.vnet.ibm.com>
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Tue, 11 Jul 2017 12:12:22 -0500	[thread overview]
Message-ID: <20170711171222.GB31603@mail.hallyn.com> (raw)
In-Reply-To: <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com>

Quoting Stefan Berger (Stefan Bergerstefanb@linux.vnet.ibm.com):
> er.kernel.org>
> X-Mailing-List: linux-kernel@vger.kernel.org
> Content-Length: 19839
> Lines: 700
> X-UID: 24770                                                 
> Status: RO
> 
> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
> 
> This patch enables security.capability in user namespaces but also
> takes a more general approach to enabling extended attributes in user
> namespaces.
> 
> The following rules describe the approach using security.foo as a
> 'user namespace enabled' extended attribute:
> 
> Reading of extended attributes:
> 
> 1a) Reading security.foo from a user namespace will read
>     security.foo@uid=<uid> of the parent user namespace instead with uid
>     being the mapping of root in that parent user namespace. An
>     exception is if root is mapped to uid 0 on the host, and in this case
>     we will read security.foo directly.
>     --> reading security.foo will read security.foo@uid=1000 for uid
>         mapping of root to 1000.
> 
> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>     parent namespace is tried to be read. This procedure is repeated up to
>     the init user namespace. This step only applies for reading of extended
>     attributes and provides the same behavior as older system where the
>     host's extended attributes applied to user namespaces.
> 
> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>    can be read. The uid within the user namespace will be mapped to the
>    corresponding uid on the host and that uid will be used in the name of
>    the extended attribute.
>    -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>       mapping of root to 1000, size of at least 2.
> 
>    All security.foo@uid=<uid> can be read (by root) on the host with values
>    of <uid> also being subject to checking for valid mappings.
> 
> 3) No other security.foo* can be read.
> 
> The same rules for reading apply to writing and removing of user
> namespace enabled extended attributes.
> 
> When listing extended attributes of a file, only those are presented
> to the user namespace that have a valid mapping. Besides that, names
> of the extended attributes are adjusted to represent the mapping.
> This means that if root is mapped to uid 1000 on the host, the
> security.foo@uid=1000 will be listed as security.foo in the user
> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
> 
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
>  fs/xattr.c               | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>  security/commoncap.c     |  36 +++-
>  security/selinux/hooks.c |   9 +-
>  3 files changed, 523 insertions(+), 31 deletions(-)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 464c94b..eacad9e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>  	return inode_permission(inode, mask);
>  }
>  
> +/*
> + * A list of extended attributes that are supported in user namespaces
> + */
> +static const char *const userns_xattrs[] = {
> +	XATTR_NAME_CAPS,
> +	NULL
> +};
> +
> +/*
> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
> + *
> + * @name:   full name of the extended attribute
> + * @prefix: do a prefix match (true) or a full match (false)
> + *
> + * This function returns < 0 if not supported, an index into userns_xattrs[]
> + * otherwise.
> + */
> +static int
> +xattr_is_userns_supported(const char *name, int prefix)
> +{
> +	int i;
> +
> +	if (!name)
> +		return -1;
> +
> +	for (i = 0; userns_xattrs[i]; i++) {
> +		if (prefix) {
> +			if (!strncmp(userns_xattrs[i], name,
> +				     strlen(userns_xattrs[i])))
> +				return i;

I think you here need to also check that the next char is either
'\0' or '.' (or maybe '@')

> +		} else {
> +			if (!strcmp(userns_xattrs[i], name))
> +				return i;
> +		}
> +	}
> +	return -1;
> +}
> +
> +/*
> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
> + *                   includes a prefix string
> + *
> + * @uid:     the uid
> + * @prefix:  prefix string; may be NULL
> + *
> + * This function returns a buffer with the string, or a NULL pointer in
> + * case of out-of-memory error.
> + */
> +static char *
> +xattr_write_uid(uid_t uid, const char *prefix)
> +{
> +	size_t buflen;
> +	char *buffer;
> +
> +	buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
> +	if (prefix)
> +		buflen += strlen(prefix);
> +
> +	buffer = kmalloc(buflen, GFP_KERNEL);
> +	if (!buffer)
> +		return NULL;
> +
> +	if (uid == 0)
> +		*buffer = 0;

Do you need to print out the prefix here?

> +	else
> +		sprintf(buffer, "%s@uid=%u",
> +			(prefix) ? prefix : "",
> +			uid);
> +
> +	return buffer;
> +}

  reply	other threads:[~2017-07-11 17:12 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 15:05 [PATCH v2] Enable namespaced file capabilities Stefan Berger
2017-07-11 15:05 ` [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger
2017-07-11 17:12   ` Serge E. Hallyn [this message]
2017-07-12  0:15     ` Stefan Berger
2017-07-12  0:47       ` Serge E. Hallyn
2017-07-12  3:45   ` Serge E. Hallyn
2017-07-12 11:35     ` Stefan Berger
2017-07-12 17:32       ` Serge E. Hallyn
2017-07-12  7:59   ` James Morris
2017-07-12 13:25   ` Eric W. Biederman
2017-07-12 17:03     ` Serge E. Hallyn
2017-07-12 22:20       ` James Morris
2017-07-13  0:33         ` Eric W. Biederman
2017-07-13  1:01           ` Serge E. Hallyn
2017-07-12 23:13       ` Eric W. Biederman
2017-07-13  0:43         ` Serge E. Hallyn
2017-07-13  0:44         ` Stefan Berger
2017-07-13  1:15           ` Theodore Ts'o
2017-07-13  2:34             ` Serge E. Hallyn
2017-07-13 12:11             ` Eric W. Biederman
2017-07-13 16:40               ` Theodore Ts'o
2017-07-13 17:05                 ` Stefan Berger
2017-07-13 17:39                   ` Eric W. Biederman
2017-07-13 19:14                     ` Theodore Ts'o
2017-07-13 19:41                       ` Serge E. Hallyn
2017-07-13 21:17                     ` Serge E. Hallyn
2017-07-18  7:01                   ` James Morris
2017-07-18 12:12                     ` Stefan Berger
2017-07-18 13:26                       ` Eric W. Biederman
2017-07-18 23:13                         ` Serge E. Hallyn
2017-07-13 17:14                 ` Eric W. Biederman
2017-07-13 17:33                   ` Stefan Berger
2017-07-13 17:49                     ` Eric W. Biederman
2017-07-13 19:48                       ` Serge E. Hallyn
2017-07-13 21:12                         ` Eric W. Biederman
     [not found]                       ` <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com>
2017-07-14  0:38                         ` Eric W. Biederman
2017-07-14 11:32                           ` Stefan Berger
2017-07-14 12:04                             ` Eric W. Biederman
2017-07-14 12:39                               ` Stefan Berger
2017-07-14 13:34                             ` Serge E. Hallyn
2017-07-14 15:22                               ` Stefan Berger
2017-07-14 17:35                                 ` Serge E. Hallyn
2017-07-14 18:17                                   ` Eric W. Biederman
2017-07-14 18:48                                   ` Mimi Zohar
2017-07-14 18:52                                     ` James Bottomley
2017-07-14 20:03                                       ` Mimi Zohar
2017-07-14 20:39                                         ` James Bottomley
2017-07-14 21:34                                           ` Theodore Ts'o
2017-07-14 23:22                                             ` Eric W. Biederman
2017-07-14 23:29                                           ` Mimi Zohar
2017-07-14 23:53                                           ` Eric W. Biederman
2017-07-14 19:29                                     ` Theodore Ts'o
2017-07-14 19:43                                       ` Mimi Zohar
     [not found]                                   ` <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>
2017-07-14 19:26                                     ` Mimi Zohar
2017-07-15  0:02                                       ` Eric W. Biederman
     [not found]                                       ` <xagsmtp3.20170715001054.9173@uk1vsc.vnet.ibm.com>
2017-07-16 11:25                                         ` Mimi Zohar
2017-07-26  3:00                                       ` Serge E. Hallyn
2017-07-26 13:57                                         ` Mimi Zohar
2017-07-14 17:36                                 ` Eric W. Biederman
2017-07-14 19:22                                   ` Stefan Berger
2017-07-13 21:21                     ` Serge E. Hallyn
2017-07-13 21:13                 ` Serge E. Hallyn
2017-07-12 17:53   ` Vivek Goyal
2017-07-12 19:19     ` Stefan Berger
2017-07-14 23:41   ` Eric W. Biederman
2017-07-15 21:27     ` Stefan Berger
2017-07-17 18:58   ` Vivek Goyal
2017-07-17 20:50     ` Stefan Berger
2017-07-18 11:48       ` Vivek Goyal
2017-07-18 12:05         ` Stefan Berger
2017-07-18 12:30           ` Vivek Goyal
2017-07-18 12:36             ` Vivek Goyal
2017-07-18 13:29               ` Eric W. Biederman
2017-07-18 13:21             ` Stefan Berger
2017-07-18 14:57               ` Vivek Goyal
2017-07-18 16:11                 ` Stefan Berger

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=20170711171222.GB31603@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=StefanBergerstefanb@linux.vnet.ibm.com \
    --cc=amir73il@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=christian.brauner@mailbox.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=tycho@docker.com \
    --cc=vgoyal@redhat.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

all inboxes | Powered by JetHome®