[PATCH] devpts: Add ptmx_uid and ptmx_gid options

[PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

It's currently impossible to mount devpts in a user namespace that
has no root user, since ptmx can't be created.  This adds options
ptmx_uid and ptmx_gid that override the default uid and gid of 0.

These options are not shown in mountinfo because they have no effect
other than changing the initial mode of ptmx, and, in particular, it
wouldn't make any sense to change them on remount.  Instead, we
disallow them on remount.

This could be changed, but we'd probably want to fix the userns
behavior of uid and gid at the same time if we did so.

Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
---
 Documentation/filesystems/devpts.txt |  4 +++
 fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
 2 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
index 68dffd87f9b7..7808e77d0d72 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -121,6 +121,10 @@ once), following user-space issues should be noted.
 
 	chmod 666 /dev/pts/ptmx
 
+   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
+   and ptmxgid options.  Both default to zero, which, in user namespaces
+   that have no root user, will cause mounting to fail.
+
 7. A mount of devpts without the 'newinstance' option results in binding to
    initial kernel mount.  This behavior while preserving legacy semantics,
    does not provide strict isolation in a container environment. i.e by
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index cfe8466f7fef..b60d1438c660 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -102,6 +102,8 @@ struct pts_mount_opts {
 	int setgid;
 	kuid_t   uid;
 	kgid_t   gid;
+	uid_t ptmx_uid;
+	gid_t ptmx_gid;
 	umode_t mode;
 	umode_t ptmxmode;
 	int newinstance;
@@ -109,8 +111,8 @@ struct pts_mount_opts {
 };
 
 enum {
-	Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
-	Opt_err
+	Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
+	Opt_newinstance,  Opt_max, Opt_err,
 };
 
 static const match_table_t tokens = {
@@ -118,6 +120,8 @@ static const match_table_t tokens = {
 	{Opt_gid, "gid=%u"},
 	{Opt_mode, "mode=%o"},
 #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
+	{Opt_ptmx_uid, "ptmxuid=%u"},
+	{Opt_ptmx_gid, "ptmxgid=%u"},
 	{Opt_ptmxmode, "ptmxmode=%o"},
 	{Opt_newinstance, "newinstance"},
 	{Opt_max, "max=%d"},
@@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 	char *p;
 	kuid_t uid;
 	kgid_t gid;
-
-	opts->setuid  = 0;
-	opts->setgid  = 0;
-	opts->uid     = GLOBAL_ROOT_UID;
-	opts->gid     = GLOBAL_ROOT_GID;
-	opts->mode    = DEVPTS_DEFAULT_MODE;
+	bool setptmxid = false;
+
+	opts->setuid   = 0;
+	opts->setgid   = 0;
+	opts->uid      = GLOBAL_ROOT_UID;
+	opts->gid      = GLOBAL_ROOT_GID;
+	opts->ptmx_uid = 0;
+	opts->ptmx_gid = 0;
+	opts->mode     = DEVPTS_DEFAULT_MODE;
 	opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
-	opts->max     = NR_UNIX98_PTY_MAX;
+	opts->max      = NR_UNIX98_PTY_MAX;
 
 	/* newinstance makes sense only on initial mount */
 	if (op == PARSE_MOUNT)
@@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 			opts->mode = option & S_IALLUGO;
 			break;
 #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
+		case Opt_ptmx_uid:
+			if (match_int(&args[0], &option))
+				return -EINVAL;
+			if (op != PARSE_MOUNT)
+				return -EINVAL;
+			opts->ptmx_uid = option;
+			setptmxid = true;
+			break;
+		case Opt_ptmx_gid:
+			if (match_int(&args[0], &option))
+				return -EINVAL;
+			if (op != PARSE_MOUNT)
+				return -EINVAL;
+			opts->ptmx_gid = option;
+			setptmxid = true;
+			break;
 		case Opt_ptmxmode:
 			if (match_octal(&args[0], &option))
 				return -EINVAL;
@@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 		}
 	}
 
+	if (setptmxid && !opts->newinstance)
+		return -EINVAL;
+
 	return 0;
 }
 
@@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
 	struct dentry *root = sb->s_root;
 	struct pts_fs_info *fsi = DEVPTS_SB(sb);
 	struct pts_mount_opts *opts = &fsi->mount_opts;
-	kuid_t root_uid;
-	kgid_t root_gid;
+	kuid_t ptmx_uid;
+	kgid_t ptmx_gid;
 
-	root_uid = make_kuid(current_user_ns(), 0);
-	root_gid = make_kgid(current_user_ns(), 0);
-	if (!uid_valid(root_uid) || !gid_valid(root_gid))
+	ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
+	ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
+	if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
 		return -EINVAL;
 
 	mutex_lock(&root->d_inode->i_mutex);
@@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
 
 	mode = S_IFCHR|opts->ptmxmode;
 	init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
-	inode->i_uid = root_uid;
-	inode->i_gid = root_gid;
+	inode->i_uid = ptmx_uid;
+	inode->i_gid = ptmx_gid;
 
 	d_add(dentry, inode);
 
-- 
2.3.0

[PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

It's currently impossible to mount devpts in a user namespace that
has no root user, since ptmx can't be created.  This adds options
ptmx_uid and ptmx_gid that override the default uid and gid of 0.

These options are not shown in mountinfo because they have no effect
other than changing the initial mode of ptmx, and, in particular, it
wouldn't make any sense to change them on remount.  Instead, we
disallow them on remount.

This could be changed, but we'd probably want to fix the userns
behavior of uid and gid at the same time if we did so.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 Documentation/filesystems/devpts.txt |  4 +++
 fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
 2 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
index 68dffd87f9b7..7808e77d0d72 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -121,6 +121,10 @@ once), following user-space issues should be noted.
 
 	chmod 666 /dev/pts/ptmx
 
+   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
+   and ptmxgid options.  Both default to zero, which, in user namespaces
+   that have no root user, will cause mounting to fail.
+
 7. A mount of devpts without the 'newinstance' option results in binding to
    initial kernel mount.  This behavior while preserving legacy semantics,
    does not provide strict isolation in a container environment. i.e by
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index cfe8466f7fef..b60d1438c660 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -102,6 +102,8 @@ struct pts_mount_opts {
 	int setgid;
 	kuid_t   uid;
 	kgid_t   gid;
+	uid_t ptmx_uid;
+	gid_t ptmx_gid;
 	umode_t mode;
 	umode_t ptmxmode;
 	int newinstance;
@@ -109,8 +111,8 @@ struct pts_mount_opts {
 };
 
 enum {
-	Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
-	Opt_err
+	Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
+	Opt_newinstance,  Opt_max, Opt_err,
 };
 
 static const match_table_t tokens = {
@@ -118,6 +120,8 @@ static const match_table_t tokens = {
 	{Opt_gid, "gid=%u"},
 	{Opt_mode, "mode=%o"},
 #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
+	{Opt_ptmx_uid, "ptmxuid=%u"},
+	{Opt_ptmx_gid, "ptmxgid=%u"},
 	{Opt_ptmxmode, "ptmxmode=%o"},
 	{Opt_newinstance, "newinstance"},
 	{Opt_max, "max=%d"},
@@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 	char *p;
 	kuid_t uid;
 	kgid_t gid;
-
-	opts->setuid  = 0;
-	opts->setgid  = 0;
-	opts->uid     = GLOBAL_ROOT_UID;
-	opts->gid     = GLOBAL_ROOT_GID;
-	opts->mode    = DEVPTS_DEFAULT_MODE;
+	bool setptmxid = false;
+
+	opts->setuid   = 0;
+	opts->setgid   = 0;
+	opts->uid      = GLOBAL_ROOT_UID;
+	opts->gid      = GLOBAL_ROOT_GID;
+	opts->ptmx_uid = 0;
+	opts->ptmx_gid = 0;
+	opts->mode     = DEVPTS_DEFAULT_MODE;
 	opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
-	opts->max     = NR_UNIX98_PTY_MAX;
+	opts->max      = NR_UNIX98_PTY_MAX;
 
 	/* newinstance makes sense only on initial mount */
 	if (op == PARSE_MOUNT)
@@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 			opts->mode = option & S_IALLUGO;
 			break;
 #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
+		case Opt_ptmx_uid:
+			if (match_int(&args[0], &option))
+				return -EINVAL;
+			if (op != PARSE_MOUNT)
+				return -EINVAL;
+			opts->ptmx_uid = option;
+			setptmxid = true;
+			break;
+		case Opt_ptmx_gid:
+			if (match_int(&args[0], &option))
+				return -EINVAL;
+			if (op != PARSE_MOUNT)
+				return -EINVAL;
+			opts->ptmx_gid = option;
+			setptmxid = true;
+			break;
 		case Opt_ptmxmode:
 			if (match_octal(&args[0], &option))
 				return -EINVAL;
@@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
 		}
 	}
 
+	if (setptmxid && !opts->newinstance)
+		return -EINVAL;
+
 	return 0;
 }
 
@@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
 	struct dentry *root = sb->s_root;
 	struct pts_fs_info *fsi = DEVPTS_SB(sb);
 	struct pts_mount_opts *opts = &fsi->mount_opts;
-	kuid_t root_uid;
-	kgid_t root_gid;
+	kuid_t ptmx_uid;
+	kgid_t ptmx_gid;
 
-	root_uid = make_kuid(current_user_ns(), 0);
-	root_gid = make_kgid(current_user_ns(), 0);
-	if (!uid_valid(root_uid) || !gid_valid(root_gid))
+	ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
+	ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
+	if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
 		return -EINVAL;
 
 	mutex_lock(&root->d_inode->i_mutex);
@@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
 
 	mode = S_IFCHR|opts->ptmxmode;
 	init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
-	inode->i_uid = root_uid;
-	inode->i_gid = root_gid;
+	inode->i_uid = ptmx_uid;
+	inode->i_gid = ptmx_gid;
 
 	d_add(dentry, inode);
 
-- 
2.3.0

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

Ping?  It's been over a month.

On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> It's currently impossible to mount devpts in a user namespace that
> has no root user, since ptmx can't be created.  This adds options
> ptmx_uid and ptmx_gid that override the default uid and gid of 0.
>
> These options are not shown in mountinfo because they have no effect
> other than changing the initial mode of ptmx, and, in particular, it
> wouldn't make any sense to change them on remount.  Instead, we
> disallow them on remount.
>
> This could be changed, but we'd probably want to fix the userns
> behavior of uid and gid at the same time if we did so.
>
> Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> ---
>  Documentation/filesystems/devpts.txt |  4 +++
>  fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
>  2 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
> index 68dffd87f9b7..7808e77d0d72 100644
> --- a/Documentation/filesystems/devpts.txt
> +++ b/Documentation/filesystems/devpts.txt
> @@ -121,6 +121,10 @@ once), following user-space issues should be noted.
>
>         chmod 666 /dev/pts/ptmx
>
> +   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
> +   and ptmxgid options.  Both default to zero, which, in user namespaces
> +   that have no root user, will cause mounting to fail.
> +
>  7. A mount of devpts without the 'newinstance' option results in binding to
>     initial kernel mount.  This behavior while preserving legacy semantics,
>     does not provide strict isolation in a container environment. i.e by
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index cfe8466f7fef..b60d1438c660 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -102,6 +102,8 @@ struct pts_mount_opts {
>         int setgid;
>         kuid_t   uid;
>         kgid_t   gid;
> +       uid_t ptmx_uid;
> +       gid_t ptmx_gid;
>         umode_t mode;
>         umode_t ptmxmode;
>         int newinstance;
> @@ -109,8 +111,8 @@ struct pts_mount_opts {
>  };
>
>  enum {
> -       Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
> -       Opt_err
> +       Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
> +       Opt_newinstance,  Opt_max, Opt_err,
>  };
>
>  static const match_table_t tokens = {
> @@ -118,6 +120,8 @@ static const match_table_t tokens = {
>         {Opt_gid, "gid=%u"},
>         {Opt_mode, "mode=%o"},
>  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> +       {Opt_ptmx_uid, "ptmxuid=%u"},
> +       {Opt_ptmx_gid, "ptmxgid=%u"},
>         {Opt_ptmxmode, "ptmxmode=%o"},
>         {Opt_newinstance, "newinstance"},
>         {Opt_max, "max=%d"},
> @@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>         char *p;
>         kuid_t uid;
>         kgid_t gid;
> -
> -       opts->setuid  = 0;
> -       opts->setgid  = 0;
> -       opts->uid     = GLOBAL_ROOT_UID;
> -       opts->gid     = GLOBAL_ROOT_GID;
> -       opts->mode    = DEVPTS_DEFAULT_MODE;
> +       bool setptmxid = false;
> +
> +       opts->setuid   = 0;
> +       opts->setgid   = 0;
> +       opts->uid      = GLOBAL_ROOT_UID;
> +       opts->gid      = GLOBAL_ROOT_GID;
> +       opts->ptmx_uid = 0;
> +       opts->ptmx_gid = 0;
> +       opts->mode     = DEVPTS_DEFAULT_MODE;
>         opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
> -       opts->max     = NR_UNIX98_PTY_MAX;
> +       opts->max      = NR_UNIX98_PTY_MAX;
>
>         /* newinstance makes sense only on initial mount */
>         if (op == PARSE_MOUNT)
> @@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>                         opts->mode = option & S_IALLUGO;
>                         break;
>  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> +               case Opt_ptmx_uid:
> +                       if (match_int(&args[0], &option))
> +                               return -EINVAL;
> +                       if (op != PARSE_MOUNT)
> +                               return -EINVAL;
> +                       opts->ptmx_uid = option;
> +                       setptmxid = true;
> +                       break;
> +               case Opt_ptmx_gid:
> +                       if (match_int(&args[0], &option))
> +                               return -EINVAL;
> +                       if (op != PARSE_MOUNT)
> +                               return -EINVAL;
> +                       opts->ptmx_gid = option;
> +                       setptmxid = true;
> +                       break;
>                 case Opt_ptmxmode:
>                         if (match_octal(&args[0], &option))
>                                 return -EINVAL;
> @@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>                 }
>         }
>
> +       if (setptmxid && !opts->newinstance)
> +               return -EINVAL;
> +
>         return 0;
>  }
>
> @@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
>         struct dentry *root = sb->s_root;
>         struct pts_fs_info *fsi = DEVPTS_SB(sb);
>         struct pts_mount_opts *opts = &fsi->mount_opts;
> -       kuid_t root_uid;
> -       kgid_t root_gid;
> +       kuid_t ptmx_uid;
> +       kgid_t ptmx_gid;
>
> -       root_uid = make_kuid(current_user_ns(), 0);
> -       root_gid = make_kgid(current_user_ns(), 0);
> -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> +       ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
> +       ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
> +       if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
>                 return -EINVAL;
>
>         mutex_lock(&root->d_inode->i_mutex);
> @@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
>
>         mode = S_IFCHR|opts->ptmxmode;
>         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> -       inode->i_uid = root_uid;
> -       inode->i_gid = root_gid;
> +       inode->i_uid = ptmx_uid;
> +       inode->i_gid = ptmx_gid;
>
>         d_add(dentry, inode);
>
> --
> 2.3.0
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

Ping?  It's been over a month.

On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> It's currently impossible to mount devpts in a user namespace that
> has no root user, since ptmx can't be created.  This adds options
> ptmx_uid and ptmx_gid that override the default uid and gid of 0.
>
> These options are not shown in mountinfo because they have no effect
> other than changing the initial mode of ptmx, and, in particular, it
> wouldn't make any sense to change them on remount.  Instead, we
> disallow them on remount.
>
> This could be changed, but we'd probably want to fix the userns
> behavior of uid and gid at the same time if we did so.
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  Documentation/filesystems/devpts.txt |  4 +++
>  fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
>  2 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
> index 68dffd87f9b7..7808e77d0d72 100644
> --- a/Documentation/filesystems/devpts.txt
> +++ b/Documentation/filesystems/devpts.txt
> @@ -121,6 +121,10 @@ once), following user-space issues should be noted.
>
>         chmod 666 /dev/pts/ptmx
>
> +   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
> +   and ptmxgid options.  Both default to zero, which, in user namespaces
> +   that have no root user, will cause mounting to fail.
> +
>  7. A mount of devpts without the 'newinstance' option results in binding to
>     initial kernel mount.  This behavior while preserving legacy semantics,
>     does not provide strict isolation in a container environment. i.e by
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index cfe8466f7fef..b60d1438c660 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -102,6 +102,8 @@ struct pts_mount_opts {
>         int setgid;
>         kuid_t   uid;
>         kgid_t   gid;
> +       uid_t ptmx_uid;
> +       gid_t ptmx_gid;
>         umode_t mode;
>         umode_t ptmxmode;
>         int newinstance;
> @@ -109,8 +111,8 @@ struct pts_mount_opts {
>  };
>
>  enum {
> -       Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
> -       Opt_err
> +       Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
> +       Opt_newinstance,  Opt_max, Opt_err,
>  };
>
>  static const match_table_t tokens = {
> @@ -118,6 +120,8 @@ static const match_table_t tokens = {
>         {Opt_gid, "gid=%u"},
>         {Opt_mode, "mode=%o"},
>  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> +       {Opt_ptmx_uid, "ptmxuid=%u"},
> +       {Opt_ptmx_gid, "ptmxgid=%u"},
>         {Opt_ptmxmode, "ptmxmode=%o"},
>         {Opt_newinstance, "newinstance"},
>         {Opt_max, "max=%d"},
> @@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>         char *p;
>         kuid_t uid;
>         kgid_t gid;
> -
> -       opts->setuid  = 0;
> -       opts->setgid  = 0;
> -       opts->uid     = GLOBAL_ROOT_UID;
> -       opts->gid     = GLOBAL_ROOT_GID;
> -       opts->mode    = DEVPTS_DEFAULT_MODE;
> +       bool setptmxid = false;
> +
> +       opts->setuid   = 0;
> +       opts->setgid   = 0;
> +       opts->uid      = GLOBAL_ROOT_UID;
> +       opts->gid      = GLOBAL_ROOT_GID;
> +       opts->ptmx_uid = 0;
> +       opts->ptmx_gid = 0;
> +       opts->mode     = DEVPTS_DEFAULT_MODE;
>         opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
> -       opts->max     = NR_UNIX98_PTY_MAX;
> +       opts->max      = NR_UNIX98_PTY_MAX;
>
>         /* newinstance makes sense only on initial mount */
>         if (op == PARSE_MOUNT)
> @@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>                         opts->mode = option & S_IALLUGO;
>                         break;
>  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> +               case Opt_ptmx_uid:
> +                       if (match_int(&args[0], &option))
> +                               return -EINVAL;
> +                       if (op != PARSE_MOUNT)
> +                               return -EINVAL;
> +                       opts->ptmx_uid = option;
> +                       setptmxid = true;
> +                       break;
> +               case Opt_ptmx_gid:
> +                       if (match_int(&args[0], &option))
> +                               return -EINVAL;
> +                       if (op != PARSE_MOUNT)
> +                               return -EINVAL;
> +                       opts->ptmx_gid = option;
> +                       setptmxid = true;
> +                       break;
>                 case Opt_ptmxmode:
>                         if (match_octal(&args[0], &option))
>                                 return -EINVAL;
> @@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
>                 }
>         }
>
> +       if (setptmxid && !opts->newinstance)
> +               return -EINVAL;
> +
>         return 0;
>  }
>
> @@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
>         struct dentry *root = sb->s_root;
>         struct pts_fs_info *fsi = DEVPTS_SB(sb);
>         struct pts_mount_opts *opts = &fsi->mount_opts;
> -       kuid_t root_uid;
> -       kgid_t root_gid;
> +       kuid_t ptmx_uid;
> +       kgid_t ptmx_gid;
>
> -       root_uid = make_kuid(current_user_ns(), 0);
> -       root_gid = make_kgid(current_user_ns(), 0);
> -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> +       ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
> +       ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
> +       if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
>                 return -EINVAL;
>
>         mutex_lock(&root->d_inode->i_mutex);
> @@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
>
>         mode = S_IFCHR|opts->ptmxmode;
>         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> -       inode->i_uid = root_uid;
> -       inode->i_gid = root_gid;
> +       inode->i_uid = ptmx_uid;
> +       inode->i_gid = ptmx_gid;
>
>         d_add(dentry, inode);
>
> --
> 2.3.0
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Thu, 2015-03-26 at 12:29 -0700, Andy Lutomirski wrote:
> Ping?  It's been over a month.

I think we all looked at this and thought "that's not a problem".  The
reason is that we all bring up full OS containers with devpts already
mounted by the host.  Even when you run from init in the Container, the
OS always seems to be prepared to find devpts already mounted.  Can you
explain a bit more what the actual problem you're trying to solve is?  I
think also I'm a bit dubious about allowing this type of flexibility
because the more lattitude container root has, the more scope there is
for a security problem.

> On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> > It's currently impossible to mount devpts in a user namespace that
> > has no root user, since ptmx can't be created.

This is where I stopped reading because it's not true ... because it is
possible, you just do it from the host as real root.

James

>   This adds options
> > ptmx_uid and ptmx_gid that override the default uid and gid of 0.
> >
> > These options are not shown in mountinfo because they have no effect
> > other than changing the initial mode of ptmx, and, in particular, it
> > wouldn't make any sense to change them on remount.  Instead, we
> > disallow them on remount.
> >
> > This could be changed, but we'd probably want to fix the userns
> > behavior of uid and gid at the same time if we did so.
> >
> > Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> > ---
> >  Documentation/filesystems/devpts.txt |  4 +++
> >  fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
> >  2 files changed, 46 insertions(+), 16 deletions(-)
> >
> > diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
> > index 68dffd87f9b7..7808e77d0d72 100644
> > --- a/Documentation/filesystems/devpts.txt
> > +++ b/Documentation/filesystems/devpts.txt
> > @@ -121,6 +121,10 @@ once), following user-space issues should be noted.
> >
> >         chmod 666 /dev/pts/ptmx
> >
> > +   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
> > +   and ptmxgid options.  Both default to zero, which, in user namespaces
> > +   that have no root user, will cause mounting to fail.
> > +
> >  7. A mount of devpts without the 'newinstance' option results in binding to
> >     initial kernel mount.  This behavior while preserving legacy semantics,
> >     does not provide strict isolation in a container environment. i.e by
> > diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> > index cfe8466f7fef..b60d1438c660 100644
> > --- a/fs/devpts/inode.c
> > +++ b/fs/devpts/inode.c
> > @@ -102,6 +102,8 @@ struct pts_mount_opts {
> >         int setgid;
> >         kuid_t   uid;
> >         kgid_t   gid;
> > +       uid_t ptmx_uid;
> > +       gid_t ptmx_gid;
> >         umode_t mode;
> >         umode_t ptmxmode;
> >         int newinstance;
> > @@ -109,8 +111,8 @@ struct pts_mount_opts {
> >  };
> >
> >  enum {
> > -       Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
> > -       Opt_err
> > +       Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
> > +       Opt_newinstance,  Opt_max, Opt_err,
> >  };
> >
> >  static const match_table_t tokens = {
> > @@ -118,6 +120,8 @@ static const match_table_t tokens = {
> >         {Opt_gid, "gid=%u"},
> >         {Opt_mode, "mode=%o"},
> >  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> > +       {Opt_ptmx_uid, "ptmxuid=%u"},
> > +       {Opt_ptmx_gid, "ptmxgid=%u"},
> >         {Opt_ptmxmode, "ptmxmode=%o"},
> >         {Opt_newinstance, "newinstance"},
> >         {Opt_max, "max=%d"},
> > @@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >         char *p;
> >         kuid_t uid;
> >         kgid_t gid;
> > -
> > -       opts->setuid  = 0;
> > -       opts->setgid  = 0;
> > -       opts->uid     = GLOBAL_ROOT_UID;
> > -       opts->gid     = GLOBAL_ROOT_GID;
> > -       opts->mode    = DEVPTS_DEFAULT_MODE;
> > +       bool setptmxid = false;
> > +
> > +       opts->setuid   = 0;
> > +       opts->setgid   = 0;
> > +       opts->uid      = GLOBAL_ROOT_UID;
> > +       opts->gid      = GLOBAL_ROOT_GID;
> > +       opts->ptmx_uid = 0;
> > +       opts->ptmx_gid = 0;
> > +       opts->mode     = DEVPTS_DEFAULT_MODE;
> >         opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
> > -       opts->max     = NR_UNIX98_PTY_MAX;
> > +       opts->max      = NR_UNIX98_PTY_MAX;
> >
> >         /* newinstance makes sense only on initial mount */
> >         if (op == PARSE_MOUNT)
> > @@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >                         opts->mode = option & S_IALLUGO;
> >                         break;
> >  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> > +               case Opt_ptmx_uid:
> > +                       if (match_int(&args[0], &option))
> > +                               return -EINVAL;
> > +                       if (op != PARSE_MOUNT)
> > +                               return -EINVAL;
> > +                       opts->ptmx_uid = option;
> > +                       setptmxid = true;
> > +                       break;
> > +               case Opt_ptmx_gid:
> > +                       if (match_int(&args[0], &option))
> > +                               return -EINVAL;
> > +                       if (op != PARSE_MOUNT)
> > +                               return -EINVAL;
> > +                       opts->ptmx_gid = option;
> > +                       setptmxid = true;
> > +                       break;
> >                 case Opt_ptmxmode:
> >                         if (match_octal(&args[0], &option))
> >                                 return -EINVAL;
> > @@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >                 }
> >         }
> >
> > +       if (setptmxid && !opts->newinstance)
> > +               return -EINVAL;
> > +
> >         return 0;
> >  }
> >
> > @@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
> >         struct dentry *root = sb->s_root;
> >         struct pts_fs_info *fsi = DEVPTS_SB(sb);
> >         struct pts_mount_opts *opts = &fsi->mount_opts;
> > -       kuid_t root_uid;
> > -       kgid_t root_gid;
> > +       kuid_t ptmx_uid;
> > +       kgid_t ptmx_gid;
> >
> > -       root_uid = make_kuid(current_user_ns(), 0);
> > -       root_gid = make_kgid(current_user_ns(), 0);
> > -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> > +       ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
> > +       ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
> > +       if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
> >                 return -EINVAL;
> >
> >         mutex_lock(&root->d_inode->i_mutex);
> > @@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
> >
> >         mode = S_IFCHR|opts->ptmxmode;
> >         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> > -       inode->i_uid = root_uid;
> > -       inode->i_gid = root_gid;
> > +       inode->i_uid = ptmx_uid;
> > +       inode->i_gid = ptmx_gid;
> >
> >         d_add(dentry, inode);
> >
> > --
> > 2.3.0
> >
> 
> 
> 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Thu, 2015-03-26 at 12:29 -0700, Andy Lutomirski wrote:
> Ping?  It's been over a month.

I think we all looked at this and thought "that's not a problem".  The
reason is that we all bring up full OS containers with devpts already
mounted by the host.  Even when you run from init in the Container, the
OS always seems to be prepared to find devpts already mounted.  Can you
explain a bit more what the actual problem you're trying to solve is?  I
think also I'm a bit dubious about allowing this type of flexibility
because the more lattitude container root has, the more scope there is
for a security problem.

> On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > It's currently impossible to mount devpts in a user namespace that
> > has no root user, since ptmx can't be created.

This is where I stopped reading because it's not true ... because it is
possible, you just do it from the host as real root.

James

>   This adds options
> > ptmx_uid and ptmx_gid that override the default uid and gid of 0.
> >
> > These options are not shown in mountinfo because they have no effect
> > other than changing the initial mode of ptmx, and, in particular, it
> > wouldn't make any sense to change them on remount.  Instead, we
> > disallow them on remount.
> >
> > This could be changed, but we'd probably want to fix the userns
> > behavior of uid and gid at the same time if we did so.
> >
> > Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > ---
> >  Documentation/filesystems/devpts.txt |  4 +++
> >  fs/devpts/inode.c                    | 58 ++++++++++++++++++++++++++----------
> >  2 files changed, 46 insertions(+), 16 deletions(-)
> >
> > diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
> > index 68dffd87f9b7..7808e77d0d72 100644
> > --- a/Documentation/filesystems/devpts.txt
> > +++ b/Documentation/filesystems/devpts.txt
> > @@ -121,6 +121,10 @@ once), following user-space issues should be noted.
> >
> >         chmod 666 /dev/pts/ptmx
> >
> > +   The ownership for /dev/pts/ptmx can be specified using the ptmxuid
> > +   and ptmxgid options.  Both default to zero, which, in user namespaces
> > +   that have no root user, will cause mounting to fail.
> > +
> >  7. A mount of devpts without the 'newinstance' option results in binding to
> >     initial kernel mount.  This behavior while preserving legacy semantics,
> >     does not provide strict isolation in a container environment. i.e by
> > diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> > index cfe8466f7fef..b60d1438c660 100644
> > --- a/fs/devpts/inode.c
> > +++ b/fs/devpts/inode.c
> > @@ -102,6 +102,8 @@ struct pts_mount_opts {
> >         int setgid;
> >         kuid_t   uid;
> >         kgid_t   gid;
> > +       uid_t ptmx_uid;
> > +       gid_t ptmx_gid;
> >         umode_t mode;
> >         umode_t ptmxmode;
> >         int newinstance;
> > @@ -109,8 +111,8 @@ struct pts_mount_opts {
> >  };
> >
> >  enum {
> > -       Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
> > -       Opt_err
> > +       Opt_uid, Opt_gid, Opt_ptmx_uid, Opt_ptmx_gid, Opt_mode, Opt_ptmxmode,
> > +       Opt_newinstance,  Opt_max, Opt_err,
> >  };
> >
> >  static const match_table_t tokens = {
> > @@ -118,6 +120,8 @@ static const match_table_t tokens = {
> >         {Opt_gid, "gid=%u"},
> >         {Opt_mode, "mode=%o"},
> >  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> > +       {Opt_ptmx_uid, "ptmxuid=%u"},
> > +       {Opt_ptmx_gid, "ptmxgid=%u"},
> >         {Opt_ptmxmode, "ptmxmode=%o"},
> >         {Opt_newinstance, "newinstance"},
> >         {Opt_max, "max=%d"},
> > @@ -162,14 +166,17 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >         char *p;
> >         kuid_t uid;
> >         kgid_t gid;
> > -
> > -       opts->setuid  = 0;
> > -       opts->setgid  = 0;
> > -       opts->uid     = GLOBAL_ROOT_UID;
> > -       opts->gid     = GLOBAL_ROOT_GID;
> > -       opts->mode    = DEVPTS_DEFAULT_MODE;
> > +       bool setptmxid = false;
> > +
> > +       opts->setuid   = 0;
> > +       opts->setgid   = 0;
> > +       opts->uid      = GLOBAL_ROOT_UID;
> > +       opts->gid      = GLOBAL_ROOT_GID;
> > +       opts->ptmx_uid = 0;
> > +       opts->ptmx_gid = 0;
> > +       opts->mode     = DEVPTS_DEFAULT_MODE;
> >         opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
> > -       opts->max     = NR_UNIX98_PTY_MAX;
> > +       opts->max      = NR_UNIX98_PTY_MAX;
> >
> >         /* newinstance makes sense only on initial mount */
> >         if (op == PARSE_MOUNT)
> > @@ -209,6 +216,22 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >                         opts->mode = option & S_IALLUGO;
> >                         break;
> >  #ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> > +               case Opt_ptmx_uid:
> > +                       if (match_int(&args[0], &option))
> > +                               return -EINVAL;
> > +                       if (op != PARSE_MOUNT)
> > +                               return -EINVAL;
> > +                       opts->ptmx_uid = option;
> > +                       setptmxid = true;
> > +                       break;
> > +               case Opt_ptmx_gid:
> > +                       if (match_int(&args[0], &option))
> > +                               return -EINVAL;
> > +                       if (op != PARSE_MOUNT)
> > +                               return -EINVAL;
> > +                       opts->ptmx_gid = option;
> > +                       setptmxid = true;
> > +                       break;
> >                 case Opt_ptmxmode:
> >                         if (match_octal(&args[0], &option))
> >                                 return -EINVAL;
> > @@ -232,6 +255,9 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts)
> >                 }
> >         }
> >
> > +       if (setptmxid && !opts->newinstance)
> > +               return -EINVAL;
> > +
> >         return 0;
> >  }
> >
> > @@ -245,12 +271,12 @@ static int mknod_ptmx(struct super_block *sb)
> >         struct dentry *root = sb->s_root;
> >         struct pts_fs_info *fsi = DEVPTS_SB(sb);
> >         struct pts_mount_opts *opts = &fsi->mount_opts;
> > -       kuid_t root_uid;
> > -       kgid_t root_gid;
> > +       kuid_t ptmx_uid;
> > +       kgid_t ptmx_gid;
> >
> > -       root_uid = make_kuid(current_user_ns(), 0);
> > -       root_gid = make_kgid(current_user_ns(), 0);
> > -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> > +       ptmx_uid = make_kuid(current_user_ns(), opts->ptmx_uid);
> > +       ptmx_gid = make_kgid(current_user_ns(), opts->ptmx_gid);
> > +       if (!uid_valid(ptmx_uid) || !gid_valid(ptmx_gid))
> >                 return -EINVAL;
> >
> >         mutex_lock(&root->d_inode->i_mutex);
> > @@ -282,8 +308,8 @@ static int mknod_ptmx(struct super_block *sb)
> >
> >         mode = S_IFCHR|opts->ptmxmode;
> >         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> > -       inode->i_uid = root_uid;
> > -       inode->i_gid = root_gid;
> > +       inode->i_uid = ptmx_uid;
> > +       inode->i_gid = ptmx_gid;
> >
> >         d_add(dentry, inode);
> >
> > --
> > 2.3.0
> >
> 
> 
> 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> 
> > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> > > It's currently impossible to mount devpts in a user namespace that
> > > has no root user, since ptmx can't be created.
> 
> This is where I stopped reading because it's not true ... because it is
> possible, you just do it from the host as real root.

The point is being able to set up a container as a user, not requiring
the setup to be run as root at all. In my case container is a desktop
application which will be started by the user, and will run as the user.
There is no root involved in the call chain at all.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
He's a war-weary Catholic boxer for the 21st century. She's a beautiful 
renegade magician's assistant looking for love in all the wrong places. 
They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> 
> > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > > It's currently impossible to mount devpts in a user namespace that
> > > has no root user, since ptmx can't be created.
> 
> This is where I stopped reading because it's not true ... because it is
> possible, you just do it from the host as real root.

The point is being able to set up a container as a user, not requiring
the setup to be run as root at all. In my case container is a desktop
application which will be started by the user, and will run as the user.
There is no root involved in the call chain at all.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's a war-weary Catholic boxer for the 21st century. She's a beautiful 
renegade magician's assistant looking for love in all the wrong places. 
They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 12:57 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>>
>> > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> > > It's currently impossible to mount devpts in a user namespace that
>> > > has no root user, since ptmx can't be created.
>>
>> This is where I stopped reading because it's not true ... because it is
>> possible, you just do it from the host as real root.
>
> The point is being able to set up a container as a user, not requiring
> the setup to be run as root at all. In my case container is a desktop
> application which will be started by the user, and will run as the user.
> There is no root involved in the call chain at all.

Even more precisely, I think the status quo has less to do with the
privilege of the userns' creator and more to do with the configuration
of the userns.  Anyone (root or otherwise) can create a userns with or
without a "root" inside.  With the current code, if you create a
userns with no inner root, you can't mount devpts inside.

This gives no security benefit exactly because nonroot users *can*
create user namespaces that contain a root user.  In the use case for
this patch, the user doesn't want to do that and then gets stuck with
the current code.


--Andy


>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> He's a war-weary Catholic boxer for the 21st century. She's a beautiful
> renegade magician's assistant looking for love in all the wrong places.
> They fight crime!
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 12:57 AM, Alexander Larsson <alexl@redhat.com> wrote:
> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>>
>> > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > > It's currently impossible to mount devpts in a user namespace that
>> > > has no root user, since ptmx can't be created.
>>
>> This is where I stopped reading because it's not true ... because it is
>> possible, you just do it from the host as real root.
>
> The point is being able to set up a container as a user, not requiring
> the setup to be run as root at all. In my case container is a desktop
> application which will be started by the user, and will run as the user.
> There is no root involved in the call chain at all.

Even more precisely, I think the status quo has less to do with the
privilege of the userns' creator and more to do with the configuration
of the userns.  Anyone (root or otherwise) can create a userns with or
without a "root" inside.  With the current code, if you create a
userns with no inner root, you can't mount devpts inside.

This gives no security benefit exactly because nonroot users *can*
create user namespaces that contain a root user.  In the use case for
this patch, the user doesn't want to do that and then gets stuck with
the current code.


--Andy


>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        alexl@redhat.com            alexander.larsson@gmail.com
> He's a war-weary Catholic boxer for the 21st century. She's a beautiful
> renegade magician's assistant looking for love in all the wrong places.
> They fight crime!
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> > 
> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> > > > It's currently impossible to mount devpts in a user namespace that
> > > > has no root user, since ptmx can't be created.
> > 
> > This is where I stopped reading because it's not true ... because it is
> > possible, you just do it from the host as real root.
> 
> The point is being able to set up a container as a user, not requiring
> the setup to be run as root at all. In my case container is a desktop
> application which will be started by the user, and will run as the user.
> There is no root involved in the call chain at all.

I don't really like that use case:  Most container setups are under the
control of an orchestration system (like LXC, OpenVZ or even Docker).
You typically get the orchestration system to do the dangerous
operations (mount being one of the bigger dangers) because it has the
capacity to vet them.  I can see the value in allowing a user to set up
a container without an oversight system, but at the same time you're
increasing the security vulnerability of the system.  Security is often
a result of policy, so now this embeds policy into the kernel.  I
strongly feel we should define the list of things we expect an
unsupervised (as in with no orchestration system) container to do and
then revisit this once we've given it some thought.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> > 
> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > > > It's currently impossible to mount devpts in a user namespace that
> > > > has no root user, since ptmx can't be created.
> > 
> > This is where I stopped reading because it's not true ... because it is
> > possible, you just do it from the host as real root.
> 
> The point is being able to set up a container as a user, not requiring
> the setup to be run as root at all. In my case container is a desktop
> application which will be started by the user, and will run as the user.
> There is no root involved in the call chain at all.

I don't really like that use case:  Most container setups are under the
control of an orchestration system (like LXC, OpenVZ or even Docker).
You typically get the orchestration system to do the dangerous
operations (mount being one of the bigger dangers) because it has the
capacity to vet them.  I can see the value in allowing a user to set up
a container without an oversight system, but at the same time you're
increasing the security vulnerability of the system.  Security is often
a result of policy, so now this embeds policy into the kernel.  I
strongly feel we should define the list of things we expect an
unsupervised (as in with no orchestration system) container to do and
then revisit this once we've given it some thought.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tis, 2015-03-31 at 16:07 +0300, James Bottomley wrote:
> On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> > On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> > > 
> > > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> > > > > It's currently impossible to mount devpts in a user namespace that
> > > > > has no root user, since ptmx can't be created.
> > > 
> > > This is where I stopped reading because it's not true ... because it is
> > > possible, you just do it from the host as real root.
> > 
> > The point is being able to set up a container as a user, not requiring
> > the setup to be run as root at all. In my case container is a desktop
> > application which will be started by the user, and will run as the user.
> > There is no root involved in the call chain at all.
> 
> I don't really like that use case:  Most container setups are under the
> control of an orchestration system (like LXC, OpenVZ or even Docker).

Well, I'm doing something different from a server side orchestration
framework. I'm doing sandboxed desktop apps.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
He's an underprivileged sweet-toothed master criminal in a wheelchair. 
She's a psychotic out-of-work opera singer with the power to see death. 
They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tis, 2015-03-31 at 16:07 +0300, James Bottomley wrote:
> On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> > On fre, 2015-03-27 at 10:03 +0100, James Bottomley 
> > > 
> > > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > > > > It's currently impossible to mount devpts in a user namespace that
> > > > > has no root user, since ptmx can't be created.
> > > 
> > > This is where I stopped reading because it's not true ... because it is
> > > possible, you just do it from the host as real root.
> > 
> > The point is being able to set up a container as a user, not requiring
> > the setup to be run as root at all. In my case container is a desktop
> > application which will be started by the user, and will run as the user.
> > There is no root involved in the call chain at all.
> 
> I don't really like that use case:  Most container setups are under the
> control of an orchestration system (like LXC, OpenVZ or even Docker).

Well, I'm doing something different from a server side orchestration
framework. I'm doing sandboxed desktop apps.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's an underprivileged sweet-toothed master criminal in a wheelchair. 
She's a psychotic out-of-work opera singer with the power to see death. 
They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >
>> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> > > > It's currently impossible to mount devpts in a user namespace that
>> > > > has no root user, since ptmx can't be created.
>> >
>> > This is where I stopped reading because it's not true ... because it is
>> > possible, you just do it from the host as real root.
>>
>> The point is being able to set up a container as a user, not requiring
>> the setup to be run as root at all. In my case container is a desktop
>> application which will be started by the user, and will run as the user.
>> There is no root involved in the call chain at all.
>
> I don't really like that use case:  Most container setups are under the
> control of an orchestration system (like LXC, OpenVZ or even Docker).
> You typically get the orchestration system to do the dangerous
> operations (mount being one of the bigger dangers) because it has the
> capacity to vet them.  I can see the value in allowing a user to set up
> a container without an oversight system, but at the same time you're
> increasing the security vulnerability of the system.  Security is often
> a result of policy, so now this embeds policy into the kernel.  I
> strongly feel we should define the list of things we expect an
> unsupervised (as in with no orchestration system) container to do and
> then revisit this once we've given it some thought.

Try thinking "sandbox", not "container".  The ability to create
sandboxes without some root-installed orchestration is incredibly
valuable.

In any event, this ship sailed quite awhile ago.  devpts is one of the
smallish number of important missing features.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >
>> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > > > It's currently impossible to mount devpts in a user namespace that
>> > > > has no root user, since ptmx can't be created.
>> >
>> > This is where I stopped reading because it's not true ... because it is
>> > possible, you just do it from the host as real root.
>>
>> The point is being able to set up a container as a user, not requiring
>> the setup to be run as root at all. In my case container is a desktop
>> application which will be started by the user, and will run as the user.
>> There is no root involved in the call chain at all.
>
> I don't really like that use case:  Most container setups are under the
> control of an orchestration system (like LXC, OpenVZ or even Docker).
> You typically get the orchestration system to do the dangerous
> operations (mount being one of the bigger dangers) because it has the
> capacity to vet them.  I can see the value in allowing a user to set up
> a container without an oversight system, but at the same time you're
> increasing the security vulnerability of the system.  Security is often
> a result of policy, so now this embeds policy into the kernel.  I
> strongly feel we should define the list of things we expect an
> unsupervised (as in with no orchestration system) container to do and
> then revisit this once we've given it some thought.

Try thinking "sandbox", not "container".  The ability to create
sandboxes without some root-installed orchestration is incredibly
valuable.

In any event, this ship sailed quite awhile ago.  devpts is one of the
smallish number of important missing features.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >
> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> > > > has no root user, since ptmx can't be created.
> >> >
> >> > This is where I stopped reading because it's not true ... because it is
> >> > possible, you just do it from the host as real root.
> >>
> >> The point is being able to set up a container as a user, not requiring
> >> the setup to be run as root at all. In my case container is a desktop
> >> application which will be started by the user, and will run as the user.
> >> There is no root involved in the call chain at all.
> >
> > I don't really like that use case:  Most container setups are under the
> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> > You typically get the orchestration system to do the dangerous
> > operations (mount being one of the bigger dangers) because it has the
> > capacity to vet them.  I can see the value in allowing a user to set up
> > a container without an oversight system, but at the same time you're
> > increasing the security vulnerability of the system.  Security is often
> > a result of policy, so now this embeds policy into the kernel.  I
> > strongly feel we should define the list of things we expect an
> > unsupervised (as in with no orchestration system) container to do and
> > then revisit this once we've given it some thought.
> 
> Try thinking "sandbox", not "container".  The ability to create
> sandboxes without some root-installed orchestration is incredibly
> valuable.

A container is anything that uses the various container APIs (mostly
cgroups and namespaces), so the set of possible containers overlaps the
set of possible sandboxes.

> In any event, this ship sailed quite awhile ago.  devpts is one of the
> smallish number of important missing features.

I'm not saying "don't do it" I'm saying think carefully about the
allowable features we permit an unprivileged user to take advantage of.
This one feels strange to me in that you're asking to give an
unprivileged user in a container more abilities than an unprivileged
user outside a container (a non-root user can't mount /dev/ptmx today).
This would mean that every unprivileged container user can now interfere
with the tty subsystem.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >
> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> > > > has no root user, since ptmx can't be created.
> >> >
> >> > This is where I stopped reading because it's not true ... because it is
> >> > possible, you just do it from the host as real root.
> >>
> >> The point is being able to set up a container as a user, not requiring
> >> the setup to be run as root at all. In my case container is a desktop
> >> application which will be started by the user, and will run as the user.
> >> There is no root involved in the call chain at all.
> >
> > I don't really like that use case:  Most container setups are under the
> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> > You typically get the orchestration system to do the dangerous
> > operations (mount being one of the bigger dangers) because it has the
> > capacity to vet them.  I can see the value in allowing a user to set up
> > a container without an oversight system, but at the same time you're
> > increasing the security vulnerability of the system.  Security is often
> > a result of policy, so now this embeds policy into the kernel.  I
> > strongly feel we should define the list of things we expect an
> > unsupervised (as in with no orchestration system) container to do and
> > then revisit this once we've given it some thought.
> 
> Try thinking "sandbox", not "container".  The ability to create
> sandboxes without some root-installed orchestration is incredibly
> valuable.

A container is anything that uses the various container APIs (mostly
cgroups and namespaces), so the set of possible containers overlaps the
set of possible sandboxes.

> In any event, this ship sailed quite awhile ago.  devpts is one of the
> smallish number of important missing features.

I'm not saying "don't do it" I'm saying think carefully about the
allowable features we permit an unprivileged user to take advantage of.
This one feels strange to me in that you're asking to give an
unprivileged user in a container more abilities than an unprivileged
user outside a container (a non-root user can't mount /dev/ptmx today).
This would mean that every unprivileged container user can now interfere
with the tty subsystem.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
>> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >> >
>> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> >> > > > It's currently impossible to mount devpts in a user namespace that
>> >> > > > has no root user, since ptmx can't be created.
>> >> >
>> >> > This is where I stopped reading because it's not true ... because it is
>> >> > possible, you just do it from the host as real root.
>> >>
>> >> The point is being able to set up a container as a user, not requiring
>> >> the setup to be run as root at all. In my case container is a desktop
>> >> application which will be started by the user, and will run as the user.
>> >> There is no root involved in the call chain at all.
>> >
>> > I don't really like that use case:  Most container setups are under the
>> > control of an orchestration system (like LXC, OpenVZ or even Docker).
>> > You typically get the orchestration system to do the dangerous
>> > operations (mount being one of the bigger dangers) because it has the
>> > capacity to vet them.  I can see the value in allowing a user to set up
>> > a container without an oversight system, but at the same time you're
>> > increasing the security vulnerability of the system.  Security is often
>> > a result of policy, so now this embeds policy into the kernel.  I
>> > strongly feel we should define the list of things we expect an
>> > unsupervised (as in with no orchestration system) container to do and
>> > then revisit this once we've given it some thought.
>>
>> Try thinking "sandbox", not "container".  The ability to create
>> sandboxes without some root-installed orchestration is incredibly
>> valuable.
>
> A container is anything that uses the various container APIs (mostly
> cgroups and namespaces), so the set of possible containers overlaps the
> set of possible sandboxes.
>
>> In any event, this ship sailed quite awhile ago.  devpts is one of the
>> smallish number of important missing features.
>
> I'm not saying "don't do it" I'm saying think carefully about the
> allowable features we permit an unprivileged user to take advantage of.
> This one feels strange to me in that you're asking to give an
> unprivileged user in a container more abilities than an unprivileged
> user outside a container (a non-root user can't mount /dev/ptmx today).
> This would mean that every unprivileged container user can now interfere
> with the tty subsystem.

That is true, but this is already the case.  The current code is:

        root_uid = make_kuid(current_user_ns(), 0);
        root_gid = make_kgid(current_user_ns(), 0);

Unprivileged tasks can make a userns and map themselves as "0" inside,
at which point the code I quoted will work fine.  The failure only
happens if they opt not to map anything at all as "0", as many
sandboxes will do.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
>> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >> >
>> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> >> > > > It's currently impossible to mount devpts in a user namespace that
>> >> > > > has no root user, since ptmx can't be created.
>> >> >
>> >> > This is where I stopped reading because it's not true ... because it is
>> >> > possible, you just do it from the host as real root.
>> >>
>> >> The point is being able to set up a container as a user, not requiring
>> >> the setup to be run as root at all. In my case container is a desktop
>> >> application which will be started by the user, and will run as the user.
>> >> There is no root involved in the call chain at all.
>> >
>> > I don't really like that use case:  Most container setups are under the
>> > control of an orchestration system (like LXC, OpenVZ or even Docker).
>> > You typically get the orchestration system to do the dangerous
>> > operations (mount being one of the bigger dangers) because it has the
>> > capacity to vet them.  I can see the value in allowing a user to set up
>> > a container without an oversight system, but at the same time you're
>> > increasing the security vulnerability of the system.  Security is often
>> > a result of policy, so now this embeds policy into the kernel.  I
>> > strongly feel we should define the list of things we expect an
>> > unsupervised (as in with no orchestration system) container to do and
>> > then revisit this once we've given it some thought.
>>
>> Try thinking "sandbox", not "container".  The ability to create
>> sandboxes without some root-installed orchestration is incredibly
>> valuable.
>
> A container is anything that uses the various container APIs (mostly
> cgroups and namespaces), so the set of possible containers overlaps the
> set of possible sandboxes.
>
>> In any event, this ship sailed quite awhile ago.  devpts is one of the
>> smallish number of important missing features.
>
> I'm not saying "don't do it" I'm saying think carefully about the
> allowable features we permit an unprivileged user to take advantage of.
> This one feels strange to me in that you're asking to give an
> unprivileged user in a container more abilities than an unprivileged
> user outside a container (a non-root user can't mount /dev/ptmx today).
> This would mean that every unprivileged container user can now interfere
> with the tty subsystem.

That is true, but this is already the case.  The current code is:

        root_uid = make_kuid(current_user_ns(), 0);
        root_gid = make_kgid(current_user_ns(), 0);

Unprivileged tasks can make a userns and map themselves as "0" inside,
at which point the code I quoted will work fine.  The failure only
happens if they opt not to map anything at all as "0", as many
sandboxes will do.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> >> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >> >
> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> >> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> >> > > > has no root user, since ptmx can't be created.
> >> >> >
> >> >> > This is where I stopped reading because it's not true ... because it is
> >> >> > possible, you just do it from the host as real root.
> >> >>
> >> >> The point is being able to set up a container as a user, not requiring
> >> >> the setup to be run as root at all. In my case container is a desktop
> >> >> application which will be started by the user, and will run as the user.
> >> >> There is no root involved in the call chain at all.
> >> >
> >> > I don't really like that use case:  Most container setups are under the
> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> >> > You typically get the orchestration system to do the dangerous
> >> > operations (mount being one of the bigger dangers) because it has the
> >> > capacity to vet them.  I can see the value in allowing a user to set up
> >> > a container without an oversight system, but at the same time you're
> >> > increasing the security vulnerability of the system.  Security is often
> >> > a result of policy, so now this embeds policy into the kernel.  I
> >> > strongly feel we should define the list of things we expect an
> >> > unsupervised (as in with no orchestration system) container to do and
> >> > then revisit this once we've given it some thought.
> >>
> >> Try thinking "sandbox", not "container".  The ability to create
> >> sandboxes without some root-installed orchestration is incredibly
> >> valuable.
> >
> > A container is anything that uses the various container APIs (mostly
> > cgroups and namespaces), so the set of possible containers overlaps the
> > set of possible sandboxes.
> >
> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
> >> smallish number of important missing features.
> >
> > I'm not saying "don't do it" I'm saying think carefully about the
> > allowable features we permit an unprivileged user to take advantage of.
> > This one feels strange to me in that you're asking to give an
> > unprivileged user in a container more abilities than an unprivileged
> > user outside a container (a non-root user can't mount /dev/ptmx today).
> > This would mean that every unprivileged container user can now interfere
> > with the tty subsystem.
> 
> That is true, but this is already the case.  The current code is:
> 
>         root_uid = make_kuid(current_user_ns(), 0);
>         root_gid = make_kgid(current_user_ns(), 0);
> 
> Unprivileged tasks can make a userns and map themselves as "0" inside,
> at which point the code I quoted will work fine.  The failure only
> happens if they opt not to map anything at all as "0", as many
> sandboxes will do.

Yes, I know.  However remember we use containers to host VPSs which
themselves can have non-root users.  I don't want a non root user inside
the VPS to be able to muck with the tty subsystem.  Your patch allows
that.  It will effectively relax security of a VPS container which is
highly undesirable.  We need the security of an operating system
container to be the same as it would be for an unvirtualized operating
system otherwise people get nasty surprises.

The fact that container root can mount /dev/ptmx is fine to me, because
container root is a privileged user inside the container.  There's still
no way, short of a privilege escalation, than a non-root container user
can become container root.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >> >
> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> >> > > > has no root user, since ptmx can't be created.
> >> >> >
> >> >> > This is where I stopped reading because it's not true ... because it is
> >> >> > possible, you just do it from the host as real root.
> >> >>
> >> >> The point is being able to set up a container as a user, not requiring
> >> >> the setup to be run as root at all. In my case container is a desktop
> >> >> application which will be started by the user, and will run as the user.
> >> >> There is no root involved in the call chain at all.
> >> >
> >> > I don't really like that use case:  Most container setups are under the
> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> >> > You typically get the orchestration system to do the dangerous
> >> > operations (mount being one of the bigger dangers) because it has the
> >> > capacity to vet them.  I can see the value in allowing a user to set up
> >> > a container without an oversight system, but at the same time you're
> >> > increasing the security vulnerability of the system.  Security is often
> >> > a result of policy, so now this embeds policy into the kernel.  I
> >> > strongly feel we should define the list of things we expect an
> >> > unsupervised (as in with no orchestration system) container to do and
> >> > then revisit this once we've given it some thought.
> >>
> >> Try thinking "sandbox", not "container".  The ability to create
> >> sandboxes without some root-installed orchestration is incredibly
> >> valuable.
> >
> > A container is anything that uses the various container APIs (mostly
> > cgroups and namespaces), so the set of possible containers overlaps the
> > set of possible sandboxes.
> >
> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
> >> smallish number of important missing features.
> >
> > I'm not saying "don't do it" I'm saying think carefully about the
> > allowable features we permit an unprivileged user to take advantage of.
> > This one feels strange to me in that you're asking to give an
> > unprivileged user in a container more abilities than an unprivileged
> > user outside a container (a non-root user can't mount /dev/ptmx today).
> > This would mean that every unprivileged container user can now interfere
> > with the tty subsystem.
> 
> That is true, but this is already the case.  The current code is:
> 
>         root_uid = make_kuid(current_user_ns(), 0);
>         root_gid = make_kgid(current_user_ns(), 0);
> 
> Unprivileged tasks can make a userns and map themselves as "0" inside,
> at which point the code I quoted will work fine.  The failure only
> happens if they opt not to map anything at all as "0", as many
> sandboxes will do.

Yes, I know.  However remember we use containers to host VPSs which
themselves can have non-root users.  I don't want a non root user inside
the VPS to be able to muck with the tty subsystem.  Your patch allows
that.  It will effectively relax security of a VPS container which is
highly undesirable.  We need the security of an operating system
container to be the same as it would be for an unvirtualized operating
system otherwise people get nasty surprises.

The fact that container root can mount /dev/ptmx is fine to me, because
container root is a privileged user inside the container.  There's still
no way, short of a privilege escalation, than a non-root container user
can become container root.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
>> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
>> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
>> >> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >> >> >
>> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> >> >> > > > It's currently impossible to mount devpts in a user namespace that
>> >> >> > > > has no root user, since ptmx can't be created.
>> >> >> >
>> >> >> > This is where I stopped reading because it's not true ... because it is
>> >> >> > possible, you just do it from the host as real root.
>> >> >>
>> >> >> The point is being able to set up a container as a user, not requiring
>> >> >> the setup to be run as root at all. In my case container is a desktop
>> >> >> application which will be started by the user, and will run as the user.
>> >> >> There is no root involved in the call chain at all.
>> >> >
>> >> > I don't really like that use case:  Most container setups are under the
>> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
>> >> > You typically get the orchestration system to do the dangerous
>> >> > operations (mount being one of the bigger dangers) because it has the
>> >> > capacity to vet them.  I can see the value in allowing a user to set up
>> >> > a container without an oversight system, but at the same time you're
>> >> > increasing the security vulnerability of the system.  Security is often
>> >> > a result of policy, so now this embeds policy into the kernel.  I
>> >> > strongly feel we should define the list of things we expect an
>> >> > unsupervised (as in with no orchestration system) container to do and
>> >> > then revisit this once we've given it some thought.
>> >>
>> >> Try thinking "sandbox", not "container".  The ability to create
>> >> sandboxes without some root-installed orchestration is incredibly
>> >> valuable.
>> >
>> > A container is anything that uses the various container APIs (mostly
>> > cgroups and namespaces), so the set of possible containers overlaps the
>> > set of possible sandboxes.
>> >
>> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
>> >> smallish number of important missing features.
>> >
>> > I'm not saying "don't do it" I'm saying think carefully about the
>> > allowable features we permit an unprivileged user to take advantage of.
>> > This one feels strange to me in that you're asking to give an
>> > unprivileged user in a container more abilities than an unprivileged
>> > user outside a container (a non-root user can't mount /dev/ptmx today).
>> > This would mean that every unprivileged container user can now interfere
>> > with the tty subsystem.
>>
>> That is true, but this is already the case.  The current code is:
>>
>>         root_uid = make_kuid(current_user_ns(), 0);
>>         root_gid = make_kgid(current_user_ns(), 0);
>>
>> Unprivileged tasks can make a userns and map themselves as "0" inside,
>> at which point the code I quoted will work fine.  The failure only
>> happens if they opt not to map anything at all as "0", as many
>> sandboxes will do.
>
> Yes, I know.  However remember we use containers to host VPSs which
> themselves can have non-root users.  I don't want a non root user inside
> the VPS to be able to muck with the tty subsystem.  Your patch allows
> that.

I don't think that this is correct.  That user can already create a
nested userns and map themselves as 0 inside it.  Then they can mount
devpts.

--Andy

>  It will effectively relax security of a VPS container which is
> highly undesirable.  We need the security of an operating system
> container to be the same as it would be for an unvirtualized operating
> system otherwise people get nasty surprises.
>
> The fact that container root can mount /dev/ptmx is fine to me, because
> container root is a privileged user inside the container.  There's still
> no way, short of a privilege escalation, than a non-root container user
> can become container root.
>
> James
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
>> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
>> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
>> >> <James.Bottomley@hansenpartnership.com> wrote:
>> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
>> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
>> >> >> >
>> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> >> >> > > > It's currently impossible to mount devpts in a user namespace that
>> >> >> > > > has no root user, since ptmx can't be created.
>> >> >> >
>> >> >> > This is where I stopped reading because it's not true ... because it is
>> >> >> > possible, you just do it from the host as real root.
>> >> >>
>> >> >> The point is being able to set up a container as a user, not requiring
>> >> >> the setup to be run as root at all. In my case container is a desktop
>> >> >> application which will be started by the user, and will run as the user.
>> >> >> There is no root involved in the call chain at all.
>> >> >
>> >> > I don't really like that use case:  Most container setups are under the
>> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
>> >> > You typically get the orchestration system to do the dangerous
>> >> > operations (mount being one of the bigger dangers) because it has the
>> >> > capacity to vet them.  I can see the value in allowing a user to set up
>> >> > a container without an oversight system, but at the same time you're
>> >> > increasing the security vulnerability of the system.  Security is often
>> >> > a result of policy, so now this embeds policy into the kernel.  I
>> >> > strongly feel we should define the list of things we expect an
>> >> > unsupervised (as in with no orchestration system) container to do and
>> >> > then revisit this once we've given it some thought.
>> >>
>> >> Try thinking "sandbox", not "container".  The ability to create
>> >> sandboxes without some root-installed orchestration is incredibly
>> >> valuable.
>> >
>> > A container is anything that uses the various container APIs (mostly
>> > cgroups and namespaces), so the set of possible containers overlaps the
>> > set of possible sandboxes.
>> >
>> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
>> >> smallish number of important missing features.
>> >
>> > I'm not saying "don't do it" I'm saying think carefully about the
>> > allowable features we permit an unprivileged user to take advantage of.
>> > This one feels strange to me in that you're asking to give an
>> > unprivileged user in a container more abilities than an unprivileged
>> > user outside a container (a non-root user can't mount /dev/ptmx today).
>> > This would mean that every unprivileged container user can now interfere
>> > with the tty subsystem.
>>
>> That is true, but this is already the case.  The current code is:
>>
>>         root_uid = make_kuid(current_user_ns(), 0);
>>         root_gid = make_kgid(current_user_ns(), 0);
>>
>> Unprivileged tasks can make a userns and map themselves as "0" inside,
>> at which point the code I quoted will work fine.  The failure only
>> happens if they opt not to map anything at all as "0", as many
>> sandboxes will do.
>
> Yes, I know.  However remember we use containers to host VPSs which
> themselves can have non-root users.  I don't want a non root user inside
> the VPS to be able to muck with the tty subsystem.  Your patch allows
> that.

I don't think that this is correct.  That user can already create a
nested userns and map themselves as 0 inside it.  Then they can mount
devpts.

--Andy

>  It will effectively relax security of a VPS container which is
> highly undesirable.  We need the security of an operating system
> container to be the same as it would be for an unvirtualized operating
> system otherwise people get nasty surprises.
>
> The fact that container root can mount /dev/ptmx is fine to me, because
> container root is a privileged user inside the container.  There's still
> no way, short of a privilege escalation, than a non-root container user
> can become container root.
>
> James
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
> >> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
> >> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> >> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> >> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> >> >> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> >> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >> >> >
> >> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> >> >> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> >> >> > > > has no root user, since ptmx can't be created.
> >> >> >> >
> >> >> >> > This is where I stopped reading because it's not true ... because it is
> >> >> >> > possible, you just do it from the host as real root.
> >> >> >>
> >> >> >> The point is being able to set up a container as a user, not requiring
> >> >> >> the setup to be run as root at all. In my case container is a desktop
> >> >> >> application which will be started by the user, and will run as the user.
> >> >> >> There is no root involved in the call chain at all.
> >> >> >
> >> >> > I don't really like that use case:  Most container setups are under the
> >> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> >> >> > You typically get the orchestration system to do the dangerous
> >> >> > operations (mount being one of the bigger dangers) because it has the
> >> >> > capacity to vet them.  I can see the value in allowing a user to set up
> >> >> > a container without an oversight system, but at the same time you're
> >> >> > increasing the security vulnerability of the system.  Security is often
> >> >> > a result of policy, so now this embeds policy into the kernel.  I
> >> >> > strongly feel we should define the list of things we expect an
> >> >> > unsupervised (as in with no orchestration system) container to do and
> >> >> > then revisit this once we've given it some thought.
> >> >>
> >> >> Try thinking "sandbox", not "container".  The ability to create
> >> >> sandboxes without some root-installed orchestration is incredibly
> >> >> valuable.
> >> >
> >> > A container is anything that uses the various container APIs (mostly
> >> > cgroups and namespaces), so the set of possible containers overlaps the
> >> > set of possible sandboxes.
> >> >
> >> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
> >> >> smallish number of important missing features.
> >> >
> >> > I'm not saying "don't do it" I'm saying think carefully about the
> >> > allowable features we permit an unprivileged user to take advantage of.
> >> > This one feels strange to me in that you're asking to give an
> >> > unprivileged user in a container more abilities than an unprivileged
> >> > user outside a container (a non-root user can't mount /dev/ptmx today).
> >> > This would mean that every unprivileged container user can now interfere
> >> > with the tty subsystem.
> >>
> >> That is true, but this is already the case.  The current code is:
> >>
> >>         root_uid = make_kuid(current_user_ns(), 0);
> >>         root_gid = make_kgid(current_user_ns(), 0);
> >>
> >> Unprivileged tasks can make a userns and map themselves as "0" inside,
> >> at which point the code I quoted will work fine.  The failure only
> >> happens if they opt not to map anything at all as "0", as many
> >> sandboxes will do.
> >
> > Yes, I know.  However remember we use containers to host VPSs which
> > themselves can have non-root users.  I don't want a non root user inside
> > the VPS to be able to muck with the tty subsystem.  Your patch allows
> > that.
> 
> I don't think that this is correct.  That user can already create a
> nested userns and map themselves as 0 inside it.  Then they can mount
> devpts.

I don't mind if they create a container and control the isolated ttys in
that sub container in the VPS; that's fine.  I do mind if they get
access to the ttys in the VPS.

If you can convince me (and the rest of Linux) that the tty subsystem
should be mountable by an unprivileged user generally, then what you
propose is OK.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
> >> On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> >> >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> >> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> >> > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> >> >> >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> >> >> >> >
> >> >> >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >> >> >> > > > It's currently impossible to mount devpts in a user namespace that
> >> >> >> > > > has no root user, since ptmx can't be created.
> >> >> >> >
> >> >> >> > This is where I stopped reading because it's not true ... because it is
> >> >> >> > possible, you just do it from the host as real root.
> >> >> >>
> >> >> >> The point is being able to set up a container as a user, not requiring
> >> >> >> the setup to be run as root at all. In my case container is a desktop
> >> >> >> application which will be started by the user, and will run as the user.
> >> >> >> There is no root involved in the call chain at all.
> >> >> >
> >> >> > I don't really like that use case:  Most container setups are under the
> >> >> > control of an orchestration system (like LXC, OpenVZ or even Docker).
> >> >> > You typically get the orchestration system to do the dangerous
> >> >> > operations (mount being one of the bigger dangers) because it has the
> >> >> > capacity to vet them.  I can see the value in allowing a user to set up
> >> >> > a container without an oversight system, but at the same time you're
> >> >> > increasing the security vulnerability of the system.  Security is often
> >> >> > a result of policy, so now this embeds policy into the kernel.  I
> >> >> > strongly feel we should define the list of things we expect an
> >> >> > unsupervised (as in with no orchestration system) container to do and
> >> >> > then revisit this once we've given it some thought.
> >> >>
> >> >> Try thinking "sandbox", not "container".  The ability to create
> >> >> sandboxes without some root-installed orchestration is incredibly
> >> >> valuable.
> >> >
> >> > A container is anything that uses the various container APIs (mostly
> >> > cgroups and namespaces), so the set of possible containers overlaps the
> >> > set of possible sandboxes.
> >> >
> >> >> In any event, this ship sailed quite awhile ago.  devpts is one of the
> >> >> smallish number of important missing features.
> >> >
> >> > I'm not saying "don't do it" I'm saying think carefully about the
> >> > allowable features we permit an unprivileged user to take advantage of.
> >> > This one feels strange to me in that you're asking to give an
> >> > unprivileged user in a container more abilities than an unprivileged
> >> > user outside a container (a non-root user can't mount /dev/ptmx today).
> >> > This would mean that every unprivileged container user can now interfere
> >> > with the tty subsystem.
> >>
> >> That is true, but this is already the case.  The current code is:
> >>
> >>         root_uid = make_kuid(current_user_ns(), 0);
> >>         root_gid = make_kgid(current_user_ns(), 0);
> >>
> >> Unprivileged tasks can make a userns and map themselves as "0" inside,
> >> at which point the code I quoted will work fine.  The failure only
> >> happens if they opt not to map anything at all as "0", as many
> >> sandboxes will do.
> >
> > Yes, I know.  However remember we use containers to host VPSs which
> > themselves can have non-root users.  I don't want a non root user inside
> > the VPS to be able to muck with the tty subsystem.  Your patch allows
> > that.
> 
> I don't think that this is correct.  That user can already create a
> nested userns and map themselves as 0 inside it.  Then they can mount
> devpts.

I don't mind if they create a container and control the isolated ttys in
that sub container in the VPS; that's fine.  I do mind if they get
access to the ttys in the VPS.

If you can convince me (and the rest of Linux) that the tty subsystem
should be mountable by an unprivileged user generally, then what you
propose is OK.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> > 
> > I don't think that this is correct.  That user can already create a
> > nested userns and map themselves as 0 inside it.  Then they can mount
> > devpts.
> 
> I don't mind if they create a container and control the isolated ttys in
> that sub container in the VPS; that's fine.  I do mind if they get
> access to the ttys in the VPS.
> 
> If you can convince me (and the rest of Linux) that the tty subsystem
> should be mountable by an unprivileged user generally, then what you
> propose is OK.

That is controlled by the general rights to mount stuff. I.e. unless you
have CAP_SYS_ADMIN in the VPS container you will not be able to mount
devpts there. You can only do it in a subcontainer where you got
permissions to mount via using user namespaces.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
He's an old-fashioned neurotic master criminal from the Mississippi 
delta. She's a manipulative extravagent widow on her way to prison for a 
murder she didn't commit. They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> > 
> > I don't think that this is correct.  That user can already create a
> > nested userns and map themselves as 0 inside it.  Then they can mount
> > devpts.
> 
> I don't mind if they create a container and control the isolated ttys in
> that sub container in the VPS; that's fine.  I do mind if they get
> access to the ttys in the VPS.
> 
> If you can convince me (and the rest of Linux) that the tty subsystem
> should be mountable by an unprivileged user generally, then what you
> propose is OK.

That is controlled by the general rights to mount stuff. I.e. unless you
have CAP_SYS_ADMIN in the VPS container you will not be able to mount
devpts there. You can only do it in a subcontainer where you got
permissions to mount via using user namespaces.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's an old-fashioned neurotic master criminal from the Mississippi 
delta. She's a manipulative extravagent widow on her way to prison for a 
murder she didn't commit. They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> > > 
> > > I don't think that this is correct.  That user can already create a
> > > nested userns and map themselves as 0 inside it.  Then they can mount
> > > devpts.
> > 
> > I don't mind if they create a container and control the isolated ttys in
> > that sub container in the VPS; that's fine.  I do mind if they get
> > access to the ttys in the VPS.
> > 
> > If you can convince me (and the rest of Linux) that the tty subsystem
> > should be mountable by an unprivileged user generally, then what you
> > propose is OK.
> 
> That is controlled by the general rights to mount stuff. I.e. unless you
> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> devpts there. You can only do it in a subcontainer where you got
> permissions to mount via using user namespaces.

OK let me try again.  Fine, if you want to speak capabilities, you've
given a non-root user an unexpected capability (the capability of
creating a ptmx device).  But you haven't used a capability separation
to do this, you've just hard coded it via a mount parameter mechanism.

If you want to do this thing, do it properly, so it's acceptable to the
whole of Linux, not a special corner case for one particular type of
container.

Security breaches are created when people code in special, little used,
corner cases because they don't get as thoroughly tested and inspected
as generally applicable mechanisms.

What you want is to be able to use the tty subsystem as a non root user:
fine, but set that up globally, don't hide it in containers so a lot
fewer people care.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[James Bottomley]

On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> > > 
> > > I don't think that this is correct.  That user can already create a
> > > nested userns and map themselves as 0 inside it.  Then they can mount
> > > devpts.
> > 
> > I don't mind if they create a container and control the isolated ttys in
> > that sub container in the VPS; that's fine.  I do mind if they get
> > access to the ttys in the VPS.
> > 
> > If you can convince me (and the rest of Linux) that the tty subsystem
> > should be mountable by an unprivileged user generally, then what you
> > propose is OK.
> 
> That is controlled by the general rights to mount stuff. I.e. unless you
> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> devpts there. You can only do it in a subcontainer where you got
> permissions to mount via using user namespaces.

OK let me try again.  Fine, if you want to speak capabilities, you've
given a non-root user an unexpected capability (the capability of
creating a ptmx device).  But you haven't used a capability separation
to do this, you've just hard coded it via a mount parameter mechanism.

If you want to do this thing, do it properly, so it's acceptable to the
whole of Linux, not a special corner case for one particular type of
container.

Security breaches are created when people code in special, little used,
corner cases because they don't get as thoroughly tested and inspected
as generally applicable mechanisms.

What you want is to be able to use the tty subsystem as a non root user:
fine, but set that up globally, don't hide it in containers so a lot
fewer people care.

James

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>> > >
>> > > I don't think that this is correct.  That user can already create a
>> > > nested userns and map themselves as 0 inside it.  Then they can mount
>> > > devpts.
>> >
>> > I don't mind if they create a container and control the isolated ttys in
>> > that sub container in the VPS; that's fine.  I do mind if they get
>> > access to the ttys in the VPS.
>> >
>> > If you can convince me (and the rest of Linux) that the tty subsystem
>> > should be mountable by an unprivileged user generally, then what you
>> > propose is OK.
>>
>> That is controlled by the general rights to mount stuff. I.e. unless you
>> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>> devpts there. You can only do it in a subcontainer where you got
>> permissions to mount via using user namespaces.
>
> OK let me try again.  Fine, if you want to speak capabilities, you've
> given a non-root user an unexpected capability (the capability of
> creating a ptmx device).  But you haven't used a capability separation
> to do this, you've just hard coded it via a mount parameter mechanism.
>
> If you want to do this thing, do it properly, so it's acceptable to the
> whole of Linux, not a special corner case for one particular type of
> container.
>
> Security breaches are created when people code in special, little used,
> corner cases because they don't get as thoroughly tested and inspected
> as generally applicable mechanisms.
>
> What you want is to be able to use the tty subsystem as a non root user:
> fine, but set that up globally, don't hide it in containers so a lot
> fewer people care.

I tend to agree, and not just for the tty subsystem.  This is an
attack surface issue.  With unprivileged user namespaces, unprivileged
users can create mount namespaces (probably a good thing for bind
mounts, etc), network namespaces (reasonably safe by themselves),
network interfaces and iptables rules (scary), fresh
instances/superblocks of some filesystems (scariness depends on the fs
-- tmpfs is probably fine), and more.

I think we should have real controls for this, and this is mostly
Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
from being mountable isn't a real control, though.

--Andy

>
> James
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>> > >
>> > > I don't think that this is correct.  That user can already create a
>> > > nested userns and map themselves as 0 inside it.  Then they can mount
>> > > devpts.
>> >
>> > I don't mind if they create a container and control the isolated ttys in
>> > that sub container in the VPS; that's fine.  I do mind if they get
>> > access to the ttys in the VPS.
>> >
>> > If you can convince me (and the rest of Linux) that the tty subsystem
>> > should be mountable by an unprivileged user generally, then what you
>> > propose is OK.
>>
>> That is controlled by the general rights to mount stuff. I.e. unless you
>> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>> devpts there. You can only do it in a subcontainer where you got
>> permissions to mount via using user namespaces.
>
> OK let me try again.  Fine, if you want to speak capabilities, you've
> given a non-root user an unexpected capability (the capability of
> creating a ptmx device).  But you haven't used a capability separation
> to do this, you've just hard coded it via a mount parameter mechanism.
>
> If you want to do this thing, do it properly, so it's acceptable to the
> whole of Linux, not a special corner case for one particular type of
> container.
>
> Security breaches are created when people code in special, little used,
> corner cases because they don't get as thoroughly tested and inspected
> as generally applicable mechanisms.
>
> What you want is to be able to use the tty subsystem as a non root user:
> fine, but set that up globally, don't hide it in containers so a lot
> fewer people care.

I tend to agree, and not just for the tty subsystem.  This is an
attack surface issue.  With unprivileged user namespaces, unprivileged
users can create mount namespaces (probably a good thing for bind
mounts, etc), network namespaces (reasonably safe by themselves),
network interfaces and iptables rules (scary), fresh
instances/superblocks of some filesystems (scariness depends on the fs
-- tmpfs is probably fine), and more.

I think we should have real controls for this, and this is mostly
Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
from being mountable isn't a real control, though.

--Andy

>
> James
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> >> > >
> >> > > I don't think that this is correct.  That user can already create a
> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
> >> > > devpts.
> >> >
> >> > I don't mind if they create a container and control the isolated ttys in
> >> > that sub container in the VPS; that's fine.  I do mind if they get
> >> > access to the ttys in the VPS.
> >> >
> >> > If you can convince me (and the rest of Linux) that the tty subsystem
> >> > should be mountable by an unprivileged user generally, then what you
> >> > propose is OK.
> >>
> >> That is controlled by the general rights to mount stuff. I.e. unless you
> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> >> devpts there. You can only do it in a subcontainer where you got
> >> permissions to mount via using user namespaces.
> >
> > OK let me try again.  Fine, if you want to speak capabilities, you've
> > given a non-root user an unexpected capability (the capability of
> > creating a ptmx device).  But you haven't used a capability separation
> > to do this, you've just hard coded it via a mount parameter mechanism.
> >
> > If you want to do this thing, do it properly, so it's acceptable to the
> > whole of Linux, not a special corner case for one particular type of
> > container.
> >
> > Security breaches are created when people code in special, little used,
> > corner cases because they don't get as thoroughly tested and inspected
> > as generally applicable mechanisms.
> >
> > What you want is to be able to use the tty subsystem as a non root user:
> > fine, but set that up globally, don't hide it in containers so a lot
> > fewer people care.
> 
> I tend to agree, and not just for the tty subsystem.  This is an
> attack surface issue.  With unprivileged user namespaces, unprivileged
> users can create mount namespaces (probably a good thing for bind
> mounts, etc), network namespaces (reasonably safe by themselves),
> network interfaces and iptables rules (scary), fresh
> instances/superblocks of some filesystems (scariness depends on the fs
> -- tmpfs is probably fine), and more.
> 
> I think we should have real controls for this, and this is mostly
> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
> from being mountable isn't a real control, though.

I'm honestly surprised that non-root is allowed to mount things in
general with user namespaces. This was long disabled use for non-root in
Fedora, but it is now enabled. 

For instance, using loopback mounted files you could probably attack
some of the less well tested filesystem implementations by feeding them
fuzzed data.

Anyway, I don't see how this affects devpts though. If you're running in
a container (or uncontained), as a regular users with no mount
capabilities you can already mount a devpts filesystem if you create a
subbcontainer with user namespaces and map your uid to 0 in the
subcontainer. Then you get a new ptmx device that you can do whatever
you want with. The mount option would let you do the same, except be
your regular uid in the subcontainer.

The only difference outside of the subcontainer is that if the outer
container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
that container. Then he can mount devpts in the outer container where he
before could only mount it in an inner container.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> >> > >
> >> > > I don't think that this is correct.  That user can already create a
> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
> >> > > devpts.
> >> >
> >> > I don't mind if they create a container and control the isolated ttys in
> >> > that sub container in the VPS; that's fine.  I do mind if they get
> >> > access to the ttys in the VPS.
> >> >
> >> > If you can convince me (and the rest of Linux) that the tty subsystem
> >> > should be mountable by an unprivileged user generally, then what you
> >> > propose is OK.
> >>
> >> That is controlled by the general rights to mount stuff. I.e. unless you
> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> >> devpts there. You can only do it in a subcontainer where you got
> >> permissions to mount via using user namespaces.
> >
> > OK let me try again.  Fine, if you want to speak capabilities, you've
> > given a non-root user an unexpected capability (the capability of
> > creating a ptmx device).  But you haven't used a capability separation
> > to do this, you've just hard coded it via a mount parameter mechanism.
> >
> > If you want to do this thing, do it properly, so it's acceptable to the
> > whole of Linux, not a special corner case for one particular type of
> > container.
> >
> > Security breaches are created when people code in special, little used,
> > corner cases because they don't get as thoroughly tested and inspected
> > as generally applicable mechanisms.
> >
> > What you want is to be able to use the tty subsystem as a non root user:
> > fine, but set that up globally, don't hide it in containers so a lot
> > fewer people care.
> 
> I tend to agree, and not just for the tty subsystem.  This is an
> attack surface issue.  With unprivileged user namespaces, unprivileged
> users can create mount namespaces (probably a good thing for bind
> mounts, etc), network namespaces (reasonably safe by themselves),
> network interfaces and iptables rules (scary), fresh
> instances/superblocks of some filesystems (scariness depends on the fs
> -- tmpfs is probably fine), and more.
> 
> I think we should have real controls for this, and this is mostly
> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
> from being mountable isn't a real control, though.

I'm honestly surprised that non-root is allowed to mount things in
general with user namespaces. This was long disabled use for non-root in
Fedora, but it is now enabled. 

For instance, using loopback mounted files you could probably attack
some of the less well tested filesystem implementations by feeding them
fuzzed data.

Anyway, I don't see how this affects devpts though. If you're running in
a container (or uncontained), as a regular users with no mount
capabilities you can already mount a devpts filesystem if you create a
subbcontainer with user namespaces and map your uid to 0 in the
subcontainer. Then you get a new ptmx device that you can do whatever
you want with. The mount option would let you do the same, except be
your regular uid in the subcontainer.

The only difference outside of the subcontainer is that if the outer
container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
that container. Then he can mount devpts in the outer container where he
before could only mount it in an inner container.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>> >> > >
>> >> > > I don't think that this is correct.  That user can already create a
>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>> >> > > devpts.
>> >> >
>> >> > I don't mind if they create a container and control the isolated ttys in
>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>> >> > access to the ttys in the VPS.
>> >> >
>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>> >> > should be mountable by an unprivileged user generally, then what you
>> >> > propose is OK.
>> >>
>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>> >> devpts there. You can only do it in a subcontainer where you got
>> >> permissions to mount via using user namespaces.
>> >
>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>> > given a non-root user an unexpected capability (the capability of
>> > creating a ptmx device).  But you haven't used a capability separation
>> > to do this, you've just hard coded it via a mount parameter mechanism.
>> >
>> > If you want to do this thing, do it properly, so it's acceptable to the
>> > whole of Linux, not a special corner case for one particular type of
>> > container.
>> >
>> > Security breaches are created when people code in special, little used,
>> > corner cases because they don't get as thoroughly tested and inspected
>> > as generally applicable mechanisms.
>> >
>> > What you want is to be able to use the tty subsystem as a non root user:
>> > fine, but set that up globally, don't hide it in containers so a lot
>> > fewer people care.
>>
>> I tend to agree, and not just for the tty subsystem.  This is an
>> attack surface issue.  With unprivileged user namespaces, unprivileged
>> users can create mount namespaces (probably a good thing for bind
>> mounts, etc), network namespaces (reasonably safe by themselves),
>> network interfaces and iptables rules (scary), fresh
>> instances/superblocks of some filesystems (scariness depends on the fs
>> -- tmpfs is probably fine), and more.
>>
>> I think we should have real controls for this, and this is mostly
>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>> from being mountable isn't a real control, though.
>
> I'm honestly surprised that non-root is allowed to mount things in
> general with user namespaces. This was long disabled use for non-root in
> Fedora, but it is now enabled.
>
> For instance, using loopback mounted files you could probably attack
> some of the less well tested filesystem implementations by feeding them
> fuzzed data.
>

You actually can't do that right now.  Filesystems have to opt in to
being mounted in unprivileged user namespaces, and no filesystems with
backing stores have opted in.  devpts has, but it's buggy without this
patch IMO.

> Anyway, I don't see how this affects devpts though. If you're running in
> a container (or uncontained), as a regular users with no mount
> capabilities you can already mount a devpts filesystem if you create a
> subbcontainer with user namespaces and map your uid to 0 in the
> subcontainer. Then you get a new ptmx device that you can do whatever
> you want with. The mount option would let you do the same, except be
> your regular uid in the subcontainer.
>
> The only difference outside of the subcontainer is that if the outer
> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
> that container. Then he can mount devpts in the outer container where he
> before could only mount it in an inner container.
>

Agreed.  Also, devpts doesn't seem scary at all to me from a userns
perspective.  Regular users on normal systems can already use ptmx,
and AFAICS basically all of the attack surface is already available
through the normal /dev/ptmx node.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl@redhat.com> wrote:
> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>> >> > >
>> >> > > I don't think that this is correct.  That user can already create a
>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>> >> > > devpts.
>> >> >
>> >> > I don't mind if they create a container and control the isolated ttys in
>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>> >> > access to the ttys in the VPS.
>> >> >
>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>> >> > should be mountable by an unprivileged user generally, then what you
>> >> > propose is OK.
>> >>
>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>> >> devpts there. You can only do it in a subcontainer where you got
>> >> permissions to mount via using user namespaces.
>> >
>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>> > given a non-root user an unexpected capability (the capability of
>> > creating a ptmx device).  But you haven't used a capability separation
>> > to do this, you've just hard coded it via a mount parameter mechanism.
>> >
>> > If you want to do this thing, do it properly, so it's acceptable to the
>> > whole of Linux, not a special corner case for one particular type of
>> > container.
>> >
>> > Security breaches are created when people code in special, little used,
>> > corner cases because they don't get as thoroughly tested and inspected
>> > as generally applicable mechanisms.
>> >
>> > What you want is to be able to use the tty subsystem as a non root user:
>> > fine, but set that up globally, don't hide it in containers so a lot
>> > fewer people care.
>>
>> I tend to agree, and not just for the tty subsystem.  This is an
>> attack surface issue.  With unprivileged user namespaces, unprivileged
>> users can create mount namespaces (probably a good thing for bind
>> mounts, etc), network namespaces (reasonably safe by themselves),
>> network interfaces and iptables rules (scary), fresh
>> instances/superblocks of some filesystems (scariness depends on the fs
>> -- tmpfs is probably fine), and more.
>>
>> I think we should have real controls for this, and this is mostly
>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>> from being mountable isn't a real control, though.
>
> I'm honestly surprised that non-root is allowed to mount things in
> general with user namespaces. This was long disabled use for non-root in
> Fedora, but it is now enabled.
>
> For instance, using loopback mounted files you could probably attack
> some of the less well tested filesystem implementations by feeding them
> fuzzed data.
>

You actually can't do that right now.  Filesystems have to opt in to
being mounted in unprivileged user namespaces, and no filesystems with
backing stores have opted in.  devpts has, but it's buggy without this
patch IMO.

> Anyway, I don't see how this affects devpts though. If you're running in
> a container (or uncontained), as a regular users with no mount
> capabilities you can already mount a devpts filesystem if you create a
> subbcontainer with user namespaces and map your uid to 0 in the
> subcontainer. Then you get a new ptmx device that you can do whatever
> you want with. The mount option would let you do the same, except be
> your regular uid in the subcontainer.
>
> The only difference outside of the subcontainer is that if the outer
> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
> that container. Then he can mount devpts in the outer container where he
> before could only mount it in an inner container.
>

Agreed.  Also, devpts doesn't seem scary at all to me from a userns
perspective.  Regular users on normal systems can already use ptmx,
and AFAICS basically all of the attack surface is already available
through the normal /dev/ptmx node.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Serge Hallyn]

Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> >> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> >> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> >> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> >> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> >> >> > >
> >> >> > > I don't think that this is correct.  That user can already create a
> >> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
> >> >> > > devpts.
> >> >> >
> >> >> > I don't mind if they create a container and control the isolated ttys in
> >> >> > that sub container in the VPS; that's fine.  I do mind if they get
> >> >> > access to the ttys in the VPS.
> >> >> >
> >> >> > If you can convince me (and the rest of Linux) that the tty subsystem
> >> >> > should be mountable by an unprivileged user generally, then what you
> >> >> > propose is OK.
> >> >>
> >> >> That is controlled by the general rights to mount stuff. I.e. unless you
> >> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> >> >> devpts there. You can only do it in a subcontainer where you got
> >> >> permissions to mount via using user namespaces.
> >> >
> >> > OK let me try again.  Fine, if you want to speak capabilities, you've
> >> > given a non-root user an unexpected capability (the capability of
> >> > creating a ptmx device).  But you haven't used a capability separation
> >> > to do this, you've just hard coded it via a mount parameter mechanism.
> >> >
> >> > If you want to do this thing, do it properly, so it's acceptable to the
> >> > whole of Linux, not a special corner case for one particular type of
> >> > container.
> >> >
> >> > Security breaches are created when people code in special, little used,
> >> > corner cases because they don't get as thoroughly tested and inspected
> >> > as generally applicable mechanisms.
> >> >
> >> > What you want is to be able to use the tty subsystem as a non root user:
> >> > fine, but set that up globally, don't hide it in containers so a lot
> >> > fewer people care.
> >>
> >> I tend to agree, and not just for the tty subsystem.  This is an
> >> attack surface issue.  With unprivileged user namespaces, unprivileged
> >> users can create mount namespaces (probably a good thing for bind
> >> mounts, etc), network namespaces (reasonably safe by themselves),
> >> network interfaces and iptables rules (scary), fresh
> >> instances/superblocks of some filesystems (scariness depends on the fs
> >> -- tmpfs is probably fine), and more.
> >>
> >> I think we should have real controls for this, and this is mostly
> >> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
> >> from being mountable isn't a real control, though.
> >
> > I'm honestly surprised that non-root is allowed to mount things in
> > general with user namespaces. This was long disabled use for non-root in
> > Fedora, but it is now enabled.
> >
> > For instance, using loopback mounted files you could probably attack
> > some of the less well tested filesystem implementations by feeding them
> > fuzzed data.
> >
> 
> You actually can't do that right now.  Filesystems have to opt in to
> being mounted in unprivileged user namespaces, and no filesystems with
> backing stores have opted in.  devpts has, but it's buggy without this
> patch IMO.
> 
> > Anyway, I don't see how this affects devpts though. If you're running in
> > a container (or uncontained), as a regular users with no mount
> > capabilities you can already mount a devpts filesystem if you create a
> > subbcontainer with user namespaces and map your uid to 0 in the
> > subcontainer. Then you get a new ptmx device that you can do whatever
> > you want with. The mount option would let you do the same, except be
> > your regular uid in the subcontainer.
> >
> > The only difference outside of the subcontainer is that if the outer
> > container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
> > that container. Then he can mount devpts in the outer container where he
> > before could only mount it in an inner container.
> >
> 
> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
> perspective.  Regular users on normal systems can already use ptmx,
> and AFAICS basically all of the attack surface is already available
> through the normal /dev/ptmx node.

I've been ignoring this thread bc I was pretty sure I had acked the
original patch.  If you don't have a record of that (or I'm plain wrong
and never did) please let me know.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Serge Hallyn]

Quoting Andy Lutomirski (luto@amacapital.net):
> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl@redhat.com> wrote:
> > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
> >> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
> >> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> >> >> > >
> >> >> > > I don't think that this is correct.  That user can already create a
> >> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
> >> >> > > devpts.
> >> >> >
> >> >> > I don't mind if they create a container and control the isolated ttys in
> >> >> > that sub container in the VPS; that's fine.  I do mind if they get
> >> >> > access to the ttys in the VPS.
> >> >> >
> >> >> > If you can convince me (and the rest of Linux) that the tty subsystem
> >> >> > should be mountable by an unprivileged user generally, then what you
> >> >> > propose is OK.
> >> >>
> >> >> That is controlled by the general rights to mount stuff. I.e. unless you
> >> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
> >> >> devpts there. You can only do it in a subcontainer where you got
> >> >> permissions to mount via using user namespaces.
> >> >
> >> > OK let me try again.  Fine, if you want to speak capabilities, you've
> >> > given a non-root user an unexpected capability (the capability of
> >> > creating a ptmx device).  But you haven't used a capability separation
> >> > to do this, you've just hard coded it via a mount parameter mechanism.
> >> >
> >> > If you want to do this thing, do it properly, so it's acceptable to the
> >> > whole of Linux, not a special corner case for one particular type of
> >> > container.
> >> >
> >> > Security breaches are created when people code in special, little used,
> >> > corner cases because they don't get as thoroughly tested and inspected
> >> > as generally applicable mechanisms.
> >> >
> >> > What you want is to be able to use the tty subsystem as a non root user:
> >> > fine, but set that up globally, don't hide it in containers so a lot
> >> > fewer people care.
> >>
> >> I tend to agree, and not just for the tty subsystem.  This is an
> >> attack surface issue.  With unprivileged user namespaces, unprivileged
> >> users can create mount namespaces (probably a good thing for bind
> >> mounts, etc), network namespaces (reasonably safe by themselves),
> >> network interfaces and iptables rules (scary), fresh
> >> instances/superblocks of some filesystems (scariness depends on the fs
> >> -- tmpfs is probably fine), and more.
> >>
> >> I think we should have real controls for this, and this is mostly
> >> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
> >> from being mountable isn't a real control, though.
> >
> > I'm honestly surprised that non-root is allowed to mount things in
> > general with user namespaces. This was long disabled use for non-root in
> > Fedora, but it is now enabled.
> >
> > For instance, using loopback mounted files you could probably attack
> > some of the less well tested filesystem implementations by feeding them
> > fuzzed data.
> >
> 
> You actually can't do that right now.  Filesystems have to opt in to
> being mounted in unprivileged user namespaces, and no filesystems with
> backing stores have opted in.  devpts has, but it's buggy without this
> patch IMO.
> 
> > Anyway, I don't see how this affects devpts though. If you're running in
> > a container (or uncontained), as a regular users with no mount
> > capabilities you can already mount a devpts filesystem if you create a
> > subbcontainer with user namespaces and map your uid to 0 in the
> > subcontainer. Then you get a new ptmx device that you can do whatever
> > you want with. The mount option would let you do the same, except be
> > your regular uid in the subcontainer.
> >
> > The only difference outside of the subcontainer is that if the outer
> > container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
> > that container. Then he can mount devpts in the outer container where he
> > before could only mount it in an inner container.
> >
> 
> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
> perspective.  Regular users on normal systems can already use ptmx,
> and AFAICS basically all of the attack surface is already available
> through the normal /dev/ptmx node.

I've been ignoring this thread bc I was pretty sure I had acked the
original patch.  If you don't have a record of that (or I'm plain wrong
and never did) please let me know.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>> >> > >
>>> >> > > I don't think that this is correct.  That user can already create a
>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>> >> > > devpts.
>>> >> >
>>> >> > I don't mind if they create a container and control the isolated ttys in
>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>> >> > access to the ttys in the VPS.
>>> >> >
>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>> >> > should be mountable by an unprivileged user generally, then what you
>>> >> > propose is OK.
>>> >>
>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>> >> devpts there. You can only do it in a subcontainer where you got
>>> >> permissions to mount via using user namespaces.
>>> >
>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>> > given a non-root user an unexpected capability (the capability of
>>> > creating a ptmx device).  But you haven't used a capability separation
>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>> >
>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>> > whole of Linux, not a special corner case for one particular type of
>>> > container.
>>> >
>>> > Security breaches are created when people code in special, little used,
>>> > corner cases because they don't get as thoroughly tested and inspected
>>> > as generally applicable mechanisms.
>>> >
>>> > What you want is to be able to use the tty subsystem as a non root user:
>>> > fine, but set that up globally, don't hide it in containers so a lot
>>> > fewer people care.
>>>
>>> I tend to agree, and not just for the tty subsystem.  This is an
>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>> users can create mount namespaces (probably a good thing for bind
>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>> network interfaces and iptables rules (scary), fresh
>>> instances/superblocks of some filesystems (scariness depends on the fs
>>> -- tmpfs is probably fine), and more.
>>>
>>> I think we should have real controls for this, and this is mostly
>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>> from being mountable isn't a real control, though.

I thought the controls for limiting how much of the userspace API
an application could use were called seccomp and seccomp2.

Do we need something like a PAM module so that we can set up these
controls during login?

>> I'm honestly surprised that non-root is allowed to mount things in
>> general with user namespaces. This was long disabled use for non-root in
>> Fedora, but it is now enabled.
>>
>> For instance, using loopback mounted files you could probably attack
>> some of the less well tested filesystem implementations by feeding them
>> fuzzed data.
>>
>
> You actually can't do that right now.  Filesystems have to opt in to
> being mounted in unprivileged user namespaces, and no filesystems with
> backing stores have opted in.  devpts has, but it's buggy without this
> patch IMO.

Arguably you should use two user namespaces.  The first to do what you
want to as root the second to run as the uid you want to run as.

>> Anyway, I don't see how this affects devpts though. If you're running in
>> a container (or uncontained), as a regular users with no mount
>> capabilities you can already mount a devpts filesystem if you create a
>> subbcontainer with user namespaces and map your uid to 0 in the
>> subcontainer. Then you get a new ptmx device that you can do whatever
>> you want with. The mount option would let you do the same, except be
>> your regular uid in the subcontainer.
>>
>> The only difference outside of the subcontainer is that if the outer
>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>> that container. Then he can mount devpts in the outer container where he
>> before could only mount it in an inner container.
>>
>
> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
> perspective.  Regular users on normal systems can already use ptmx,
> and AFAICS basically all of the attack surface is already available
> through the normal /dev/ptmx node.

My only real take is that there are a lot more places that you need to
tweak beyond devpts.  So this patch seemed lacking and boring.

Beyond that until I get the mount namespace sorted out things are pretty
much in a feature freeze because I can't multitask well enough to do
complicated patches and take feature patches.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto@amacapital.net> writes:

> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl@redhat.com> wrote:
>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>> <James.Bottomley@hansenpartnership.com> wrote:
>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>> >> > >
>>> >> > > I don't think that this is correct.  That user can already create a
>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>> >> > > devpts.
>>> >> >
>>> >> > I don't mind if they create a container and control the isolated ttys in
>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>> >> > access to the ttys in the VPS.
>>> >> >
>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>> >> > should be mountable by an unprivileged user generally, then what you
>>> >> > propose is OK.
>>> >>
>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>> >> devpts there. You can only do it in a subcontainer where you got
>>> >> permissions to mount via using user namespaces.
>>> >
>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>> > given a non-root user an unexpected capability (the capability of
>>> > creating a ptmx device).  But you haven't used a capability separation
>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>> >
>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>> > whole of Linux, not a special corner case for one particular type of
>>> > container.
>>> >
>>> > Security breaches are created when people code in special, little used,
>>> > corner cases because they don't get as thoroughly tested and inspected
>>> > as generally applicable mechanisms.
>>> >
>>> > What you want is to be able to use the tty subsystem as a non root user:
>>> > fine, but set that up globally, don't hide it in containers so a lot
>>> > fewer people care.
>>>
>>> I tend to agree, and not just for the tty subsystem.  This is an
>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>> users can create mount namespaces (probably a good thing for bind
>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>> network interfaces and iptables rules (scary), fresh
>>> instances/superblocks of some filesystems (scariness depends on the fs
>>> -- tmpfs is probably fine), and more.
>>>
>>> I think we should have real controls for this, and this is mostly
>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>> from being mountable isn't a real control, though.

I thought the controls for limiting how much of the userspace API
an application could use were called seccomp and seccomp2.

Do we need something like a PAM module so that we can set up these
controls during login?

>> I'm honestly surprised that non-root is allowed to mount things in
>> general with user namespaces. This was long disabled use for non-root in
>> Fedora, but it is now enabled.
>>
>> For instance, using loopback mounted files you could probably attack
>> some of the less well tested filesystem implementations by feeding them
>> fuzzed data.
>>
>
> You actually can't do that right now.  Filesystems have to opt in to
> being mounted in unprivileged user namespaces, and no filesystems with
> backing stores have opted in.  devpts has, but it's buggy without this
> patch IMO.

Arguably you should use two user namespaces.  The first to do what you
want to as root the second to run as the uid you want to run as.

>> Anyway, I don't see how this affects devpts though. If you're running in
>> a container (or uncontained), as a regular users with no mount
>> capabilities you can already mount a devpts filesystem if you create a
>> subbcontainer with user namespaces and map your uid to 0 in the
>> subcontainer. Then you get a new ptmx device that you can do whatever
>> you want with. The mount option would let you do the same, except be
>> your regular uid in the subcontainer.
>>
>> The only difference outside of the subcontainer is that if the outer
>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>> that container. Then he can mount devpts in the outer container where he
>> before could only mount it in an inner container.
>>
>
> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
> perspective.  Regular users on normal systems can already use ptmx,
> and AFAICS basically all of the attack surface is already available
> through the normal /dev/ptmx node.

My only real take is that there are a lot more places that you need to
tweak beyond devpts.  So this patch seemed lacking and boring.

Beyond that until I get the mount namespace sorted out things are pretty
much in a feature freeze because I can't multitask well enough to do
complicated patches and take feature patches.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tor, 2015-03-26 at 12:29 -0700, Andy Lutomirski wrote:
> Ping?  It's been over a month.

Ping again. I've tested this with 
https://github.com/alexlarsson/xdg-app/tree/wip/userns
and this is the final kernel change needed to allow desktop sandboxing
without any raised priviledges (setuid etc).

So, 
Tested-by: alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org

And please, can we get some eyeballs on this, it really is very useful
(and very simple too).

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
He's a hate-fuelled sweet-toothed cat burglar on his last day in the job. 
She's a chain-smoking mute Hell's Angel who believes she is the 
reincarnation of an ancient Egyptian queen. They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On tor, 2015-03-26 at 12:29 -0700, Andy Lutomirski wrote:
> Ping?  It's been over a month.

Ping again. I've tested this with 
https://github.com/alexlarsson/xdg-app/tree/wip/userns
and this is the final kernel change needed to allow desktop sandboxing
without any raised priviledges (setuid etc).

So, 
Tested-by: alexl@redhat.com

And please, can we get some eyeballs on this, it really is very useful
(and very simple too).

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's a hate-fuelled sweet-toothed cat burglar on his last day in the job. 
She's a chain-smoking mute Hell's Angel who believes she is the 
reincarnation of an ancient Egyptian queen. They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>
>> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>>> >> > >
>>>> >> > > I don't think that this is correct.  That user can already create a
>>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>>> >> > > devpts.
>>>> >> >
>>>> >> > I don't mind if they create a container and control the isolated ttys in
>>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>>> >> > access to the ttys in the VPS.
>>>> >> >
>>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>>> >> > should be mountable by an unprivileged user generally, then what you
>>>> >> > propose is OK.
>>>> >>
>>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>>> >> devpts there. You can only do it in a subcontainer where you got
>>>> >> permissions to mount via using user namespaces.
>>>> >
>>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>>> > given a non-root user an unexpected capability (the capability of
>>>> > creating a ptmx device).  But you haven't used a capability separation
>>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>>> >
>>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>>> > whole of Linux, not a special corner case for one particular type of
>>>> > container.
>>>> >
>>>> > Security breaches are created when people code in special, little used,
>>>> > corner cases because they don't get as thoroughly tested and inspected
>>>> > as generally applicable mechanisms.
>>>> >
>>>> > What you want is to be able to use the tty subsystem as a non root user:
>>>> > fine, but set that up globally, don't hide it in containers so a lot
>>>> > fewer people care.
>>>>
>>>> I tend to agree, and not just for the tty subsystem.  This is an
>>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>>> users can create mount namespaces (probably a good thing for bind
>>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>>> network interfaces and iptables rules (scary), fresh
>>>> instances/superblocks of some filesystems (scariness depends on the fs
>>>> -- tmpfs is probably fine), and more.
>>>>
>>>> I think we should have real controls for this, and this is mostly
>>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>>> from being mountable isn't a real control, though.
>
> I thought the controls for limiting how much of the userspace API
> an application could use were called seccomp and seccomp2.
>
> Do we need something like a PAM module so that we can set up these
> controls during login?
>
>>> I'm honestly surprised that non-root is allowed to mount things in
>>> general with user namespaces. This was long disabled use for non-root in
>>> Fedora, but it is now enabled.
>>>
>>> For instance, using loopback mounted files you could probably attack
>>> some of the less well tested filesystem implementations by feeding them
>>> fuzzed data.
>>>
>>
>> You actually can't do that right now.  Filesystems have to opt in to
>> being mounted in unprivileged user namespaces, and no filesystems with
>> backing stores have opted in.  devpts has, but it's buggy without this
>> patch IMO.
>
> Arguably you should use two user namespaces.  The first to do what you
> want to as root the second to run as the uid you want to run as.
>
>>> Anyway, I don't see how this affects devpts though. If you're running in
>>> a container (or uncontained), as a regular users with no mount
>>> capabilities you can already mount a devpts filesystem if you create a
>>> subbcontainer with user namespaces and map your uid to 0 in the
>>> subcontainer. Then you get a new ptmx device that you can do whatever
>>> you want with. The mount option would let you do the same, except be
>>> your regular uid in the subcontainer.
>>>
>>> The only difference outside of the subcontainer is that if the outer
>>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>>> that container. Then he can mount devpts in the outer container where he
>>> before could only mount it in an inner container.
>>>
>>
>> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
>> perspective.  Regular users on normal systems can already use ptmx,
>> and AFAICS basically all of the attack surface is already available
>> through the normal /dev/ptmx node.
>
> My only real take is that there are a lot more places that you need to
> tweak beyond devpts.  So this patch seemed lacking and boring.
>
> Beyond that until I get the mount namespace sorted out things are pretty
> much in a feature freeze because I can't multitask well enough to do
> complicated patches and take feature patches.
>

Eric, do you think you have time now to take a look at this patch?

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl@redhat.com> wrote:
>>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>>> >> > >
>>>> >> > > I don't think that this is correct.  That user can already create a
>>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>>> >> > > devpts.
>>>> >> >
>>>> >> > I don't mind if they create a container and control the isolated ttys in
>>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>>> >> > access to the ttys in the VPS.
>>>> >> >
>>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>>> >> > should be mountable by an unprivileged user generally, then what you
>>>> >> > propose is OK.
>>>> >>
>>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>>> >> devpts there. You can only do it in a subcontainer where you got
>>>> >> permissions to mount via using user namespaces.
>>>> >
>>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>>> > given a non-root user an unexpected capability (the capability of
>>>> > creating a ptmx device).  But you haven't used a capability separation
>>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>>> >
>>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>>> > whole of Linux, not a special corner case for one particular type of
>>>> > container.
>>>> >
>>>> > Security breaches are created when people code in special, little used,
>>>> > corner cases because they don't get as thoroughly tested and inspected
>>>> > as generally applicable mechanisms.
>>>> >
>>>> > What you want is to be able to use the tty subsystem as a non root user:
>>>> > fine, but set that up globally, don't hide it in containers so a lot
>>>> > fewer people care.
>>>>
>>>> I tend to agree, and not just for the tty subsystem.  This is an
>>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>>> users can create mount namespaces (probably a good thing for bind
>>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>>> network interfaces and iptables rules (scary), fresh
>>>> instances/superblocks of some filesystems (scariness depends on the fs
>>>> -- tmpfs is probably fine), and more.
>>>>
>>>> I think we should have real controls for this, and this is mostly
>>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>>> from being mountable isn't a real control, though.
>
> I thought the controls for limiting how much of the userspace API
> an application could use were called seccomp and seccomp2.
>
> Do we need something like a PAM module so that we can set up these
> controls during login?
>
>>> I'm honestly surprised that non-root is allowed to mount things in
>>> general with user namespaces. This was long disabled use for non-root in
>>> Fedora, but it is now enabled.
>>>
>>> For instance, using loopback mounted files you could probably attack
>>> some of the less well tested filesystem implementations by feeding them
>>> fuzzed data.
>>>
>>
>> You actually can't do that right now.  Filesystems have to opt in to
>> being mounted in unprivileged user namespaces, and no filesystems with
>> backing stores have opted in.  devpts has, but it's buggy without this
>> patch IMO.
>
> Arguably you should use two user namespaces.  The first to do what you
> want to as root the second to run as the uid you want to run as.
>
>>> Anyway, I don't see how this affects devpts though. If you're running in
>>> a container (or uncontained), as a regular users with no mount
>>> capabilities you can already mount a devpts filesystem if you create a
>>> subbcontainer with user namespaces and map your uid to 0 in the
>>> subcontainer. Then you get a new ptmx device that you can do whatever
>>> you want with. The mount option would let you do the same, except be
>>> your regular uid in the subcontainer.
>>>
>>> The only difference outside of the subcontainer is that if the outer
>>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>>> that container. Then he can mount devpts in the outer container where he
>>> before could only mount it in an inner container.
>>>
>>
>> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
>> perspective.  Regular users on normal systems can already use ptmx,
>> and AFAICS basically all of the attack surface is already available
>> through the normal /dev/ptmx node.
>
> My only real take is that there are a lot more places that you need to
> tweak beyond devpts.  So this patch seemed lacking and boring.
>
> Beyond that until I get the mount namespace sorted out things are pretty
> much in a feature freeze because I can't multitask well enough to do
> complicated patches and take feature patches.
>

Eric, do you think you have time now to take a look at this patch?

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>
>>> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>>> <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>>>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>>>> >> > >
>>>>> >> > > I don't think that this is correct.  That user can already create a
>>>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>>>> >> > > devpts.
>>>>> >> >
>>>>> >> > I don't mind if they create a container and control the isolated ttys in
>>>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>>>> >> > access to the ttys in the VPS.
>>>>> >> >
>>>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>>>> >> > should be mountable by an unprivileged user generally, then what you
>>>>> >> > propose is OK.
>>>>> >>
>>>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>>>> >> devpts there. You can only do it in a subcontainer where you got
>>>>> >> permissions to mount via using user namespaces.
>>>>> >
>>>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>>>> > given a non-root user an unexpected capability (the capability of
>>>>> > creating a ptmx device).  But you haven't used a capability separation
>>>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>>>> >
>>>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>>>> > whole of Linux, not a special corner case for one particular type of
>>>>> > container.
>>>>> >
>>>>> > Security breaches are created when people code in special, little used,
>>>>> > corner cases because they don't get as thoroughly tested and inspected
>>>>> > as generally applicable mechanisms.
>>>>> >
>>>>> > What you want is to be able to use the tty subsystem as a non root user:
>>>>> > fine, but set that up globally, don't hide it in containers so a lot
>>>>> > fewer people care.
>>>>>
>>>>> I tend to agree, and not just for the tty subsystem.  This is an
>>>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>>>> users can create mount namespaces (probably a good thing for bind
>>>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>>>> network interfaces and iptables rules (scary), fresh
>>>>> instances/superblocks of some filesystems (scariness depends on the fs
>>>>> -- tmpfs is probably fine), and more.
>>>>>
>>>>> I think we should have real controls for this, and this is mostly
>>>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>>>> from being mountable isn't a real control, though.
>>
>> I thought the controls for limiting how much of the userspace API
>> an application could use were called seccomp and seccomp2.
>>
>> Do we need something like a PAM module so that we can set up these
>> controls during login?
>>
>>>> I'm honestly surprised that non-root is allowed to mount things in
>>>> general with user namespaces. This was long disabled use for non-root in
>>>> Fedora, but it is now enabled.
>>>>
>>>> For instance, using loopback mounted files you could probably attack
>>>> some of the less well tested filesystem implementations by feeding them
>>>> fuzzed data.
>>>>
>>>
>>> You actually can't do that right now.  Filesystems have to opt in to
>>> being mounted in unprivileged user namespaces, and no filesystems with
>>> backing stores have opted in.  devpts has, but it's buggy without this
>>> patch IMO.
>>
>> Arguably you should use two user namespaces.  The first to do what you
>> want to as root the second to run as the uid you want to run as.
>>
>>>> Anyway, I don't see how this affects devpts though. If you're running in
>>>> a container (or uncontained), as a regular users with no mount
>>>> capabilities you can already mount a devpts filesystem if you create a
>>>> subbcontainer with user namespaces and map your uid to 0 in the
>>>> subcontainer. Then you get a new ptmx device that you can do whatever
>>>> you want with. The mount option would let you do the same, except be
>>>> your regular uid in the subcontainer.
>>>>
>>>> The only difference outside of the subcontainer is that if the outer
>>>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>>>> that container. Then he can mount devpts in the outer container where he
>>>> before could only mount it in an inner container.
>>>>
>>>
>>> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
>>> perspective.  Regular users on normal systems can already use ptmx,
>>> and AFAICS basically all of the attack surface is already available
>>> through the normal /dev/ptmx node.
>>
>> My only real take is that there are a lot more places that you need to
>> tweak beyond devpts.  So this patch seemed lacking and boring.
>>
>> Beyond that until I get the mount namespace sorted out things are pretty
>> much in a feature freeze because I can't multitask well enough to do
>> complicated patches and take feature patches.
>>
>
> Eric, do you think you have time now to take a look at this patch?

I am much closer.  Escaping bind mounts is still not yet fixed but I
have code that almost works.

My gut feel still says that two user namespaces one where your 0 is
mapped to your uid and a second where your uid is identity mapped is the
preferrable configuration, and makes this patch unnecessary.

I don't think I have heard anyone describe why using a pair of user
namespaces is a problem.

Conceptually as the patch is an efficiency hack on something we can
already do I don't have any semantic grounds to refuse it.  There remain
maintenance concerns (how much else will need this kind of hack) code
code complexity concerns, and is the patch buggy concerns.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto@amacapital.net> writes:

> On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <alexl@redhat.com> wrote:
>>>> On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>>> On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>>> > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote:
>>>>> >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote:
>>>>> >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
>>>>> >> > >
>>>>> >> > > I don't think that this is correct.  That user can already create a
>>>>> >> > > nested userns and map themselves as 0 inside it.  Then they can mount
>>>>> >> > > devpts.
>>>>> >> >
>>>>> >> > I don't mind if they create a container and control the isolated ttys in
>>>>> >> > that sub container in the VPS; that's fine.  I do mind if they get
>>>>> >> > access to the ttys in the VPS.
>>>>> >> >
>>>>> >> > If you can convince me (and the rest of Linux) that the tty subsystem
>>>>> >> > should be mountable by an unprivileged user generally, then what you
>>>>> >> > propose is OK.
>>>>> >>
>>>>> >> That is controlled by the general rights to mount stuff. I.e. unless you
>>>>> >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount
>>>>> >> devpts there. You can only do it in a subcontainer where you got
>>>>> >> permissions to mount via using user namespaces.
>>>>> >
>>>>> > OK let me try again.  Fine, if you want to speak capabilities, you've
>>>>> > given a non-root user an unexpected capability (the capability of
>>>>> > creating a ptmx device).  But you haven't used a capability separation
>>>>> > to do this, you've just hard coded it via a mount parameter mechanism.
>>>>> >
>>>>> > If you want to do this thing, do it properly, so it's acceptable to the
>>>>> > whole of Linux, not a special corner case for one particular type of
>>>>> > container.
>>>>> >
>>>>> > Security breaches are created when people code in special, little used,
>>>>> > corner cases because they don't get as thoroughly tested and inspected
>>>>> > as generally applicable mechanisms.
>>>>> >
>>>>> > What you want is to be able to use the tty subsystem as a non root user:
>>>>> > fine, but set that up globally, don't hide it in containers so a lot
>>>>> > fewer people care.
>>>>>
>>>>> I tend to agree, and not just for the tty subsystem.  This is an
>>>>> attack surface issue.  With unprivileged user namespaces, unprivileged
>>>>> users can create mount namespaces (probably a good thing for bind
>>>>> mounts, etc), network namespaces (reasonably safe by themselves),
>>>>> network interfaces and iptables rules (scary), fresh
>>>>> instances/superblocks of some filesystems (scariness depends on the fs
>>>>> -- tmpfs is probably fine), and more.
>>>>>
>>>>> I think we should have real controls for this, and this is mostly
>>>>> Eric's domain.  Eric?  A silly issue that sometimes prevents devpts
>>>>> from being mountable isn't a real control, though.
>>
>> I thought the controls for limiting how much of the userspace API
>> an application could use were called seccomp and seccomp2.
>>
>> Do we need something like a PAM module so that we can set up these
>> controls during login?
>>
>>>> I'm honestly surprised that non-root is allowed to mount things in
>>>> general with user namespaces. This was long disabled use for non-root in
>>>> Fedora, but it is now enabled.
>>>>
>>>> For instance, using loopback mounted files you could probably attack
>>>> some of the less well tested filesystem implementations by feeding them
>>>> fuzzed data.
>>>>
>>>
>>> You actually can't do that right now.  Filesystems have to opt in to
>>> being mounted in unprivileged user namespaces, and no filesystems with
>>> backing stores have opted in.  devpts has, but it's buggy without this
>>> patch IMO.
>>
>> Arguably you should use two user namespaces.  The first to do what you
>> want to as root the second to run as the uid you want to run as.
>>
>>>> Anyway, I don't see how this affects devpts though. If you're running in
>>>> a container (or uncontained), as a regular users with no mount
>>>> capabilities you can already mount a devpts filesystem if you create a
>>>> subbcontainer with user namespaces and map your uid to 0 in the
>>>> subcontainer. Then you get a new ptmx device that you can do whatever
>>>> you want with. The mount option would let you do the same, except be
>>>> your regular uid in the subcontainer.
>>>>
>>>> The only difference outside of the subcontainer is that if the outer
>>>> container has no uid 0 mapped, yet the user has CAP_SYSADMIN rights in
>>>> that container. Then he can mount devpts in the outer container where he
>>>> before could only mount it in an inner container.
>>>>
>>>
>>> Agreed.  Also, devpts doesn't seem scary at all to me from a userns
>>> perspective.  Regular users on normal systems can already use ptmx,
>>> and AFAICS basically all of the attack surface is already available
>>> through the normal /dev/ptmx node.
>>
>> My only real take is that there are a lot more places that you need to
>> tweak beyond devpts.  So this patch seemed lacking and boring.
>>
>> Beyond that until I get the mount namespace sorted out things are pretty
>> much in a feature freeze because I can't multitask well enough to do
>> complicated patches and take feature patches.
>>
>
> Eric, do you think you have time now to take a look at this patch?

I am much closer.  Escaping bind mounts is still not yet fixed but I
have code that almost works.

My gut feel still says that two user namespaces one where your 0 is
mapped to your uid and a second where your uid is identity mapped is the
preferrable configuration, and makes this patch unnecessary.

I don't think I have heard anyone describe why using a pair of user
namespaces is a problem.

Conceptually as the patch is an efficiency hack on something we can
already do I don't have any semantic grounds to refuse it.  There remain
maintenance concerns (how much else will need this kind of hack) code
code complexity concerns, and is the patch buggy concerns.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> 
> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> > > 
> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
> > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
> > > > > > > wrote:
> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
> > > > > > > > wrote:
> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski 
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > I don't think that this is correct.  That user can 
> > > > > > > > > > already create a
> > > > > > > > > > nested userns and map themselves as 0 inside it. 
> > > > > > > > > >  Then they can mount
> > > > > > > > > > devpts.
> > > > > > > > > 
> > > > > > > > > I don't mind if they create a container and control 
> > > > > > > > > the isolated ttys in
> > > > > > > > > that sub container in the VPS; that's fine.  I do 
> > > > > > > > > mind if they get
> > > > > > > > > access to the ttys in the VPS.
> > > > > > > > > 
> > > > > > > > > If you can convince me (and the rest of Linux) that 
> > > > > > > > > the tty subsystem
> > > > > > > > > should be mountable by an unprivileged user 
> > > > > > > > > generally, then what you
> > > > > > > > > propose is OK.
> > > > > > > > 
> > > > > > > > That is controlled by the general rights to mount 
> > > > > > > > stuff. I.e. unless you
> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be 
> > > > > > > > able to mount
> > > > > > > > devpts there. You can only do it in a subcontainer 
> > > > > > > > where you got
> > > > > > > > permissions to mount via using user namespaces.
> > > > > > > 
> > > > > > > OK let me try again.  Fine, if you want to speak 
> > > > > > > capabilities, you've
> > > > > > > given a non-root user an unexpected capability (the 
> > > > > > > capability of
> > > > > > > creating a ptmx device).  But you haven't used a 
> > > > > > > capability separation
> > > > > > > to do this, you've just hard coded it via a mount 
> > > > > > > parameter mechanism.
> > > > > > > 
> > > > > > > If you want to do this thing, do it properly, so it's 
> > > > > > > acceptable to the
> > > > > > > whole of Linux, not a special corner case for one 
> > > > > > > particular type of
> > > > > > > container.
> > > > > > > 
> > > > > > > Security breaches are created when people code in 
> > > > > > > special, little used,
> > > > > > > corner cases because they don't get as thoroughly tested 
> > > > > > > and inspected
> > > > > > > as generally applicable mechanisms.
> > > > > > > 
> > > > > > > What you want is to be able to use the tty subsystem as a 
> > > > > > > non root user:
> > > > > > > fine, but set that up globally, don't hide it in 
> > > > > > > containers so a lot
> > > > > > > fewer people care.
> > > > > > 
> > > > > > I tend to agree, and not just for the tty subsystem.  This 
> > > > > > is an
> > > > > > attack surface issue.  With unprivileged user namespaces, 
> > > > > > unprivileged
> > > > > > users can create mount namespaces (probably a good thing 
> > > > > > for bind
> > > > > > mounts, etc), network namespaces (reasonably safe by 
> > > > > > themselves),
> > > > > > network interfaces and iptables rules (scary), fresh
> > > > > > instances/superblocks of some filesystems (scariness 
> > > > > > depends on the fs
> > > > > > -- tmpfs is probably fine), and more.
> > > > > > 
> > > > > > I think we should have real controls for this, and this is 
> > > > > > mostly
> > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
> > > > > > prevents devpts
> > > > > > from being mountable isn't a real control, though.
> > > 
> > > I thought the controls for limiting how much of the userspace API
> > > an application could use were called seccomp and seccomp2.
> > > 
> > > Do we need something like a PAM module so that we can set up 
> > > these
> > > controls during login?
> > > 
> > > > > I'm honestly surprised that non-root is allowed to mount 
> > > > > things in
> > > > > general with user namespaces. This was long disabled use for 
> > > > > non-root in
> > > > > Fedora, but it is now enabled.
> > > > > 
> > > > > For instance, using loopback mounted files you could probably 
> > > > > attack
> > > > > some of the less well tested filesystem implementations by 
> > > > > feeding them
> > > > > fuzzed data.
> > > > > 
> > > > 
> > > > You actually can't do that right now.  Filesystems have to opt 
> > > > in to
> > > > being mounted in unprivileged user namespaces, and no 
> > > > filesystems with
> > > > backing stores have opted in.  devpts has, but it's buggy 
> > > > without this
> > > > patch IMO.
> > > 
> > > Arguably you should use two user namespaces.  The first to do 
> > > what you
> > > want to as root the second to run as the uid you want to run as.
> > > 
> > > > > Anyway, I don't see how this affects devpts though. If you're 
> > > > > running in
> > > > > a container (or uncontained), as a regular users with no 
> > > > > mount
> > > > > capabilities you can already mount a devpts filesystem if you 
> > > > > create a
> > > > > subbcontainer with user namespaces and map your uid to 0 in 
> > > > > the
> > > > > subcontainer. Then you get a new ptmx device that you can do 
> > > > > whatever
> > > > > you want with. The mount option would let you do the same, 
> > > > > except be
> > > > > your regular uid in the subcontainer.
> > > > > 
> > > > > The only difference outside of the subcontainer is that if 
> > > > > the outer
> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN 
> > > > > rights in
> > > > > that container. Then he can mount devpts in the outer 
> > > > > container where he
> > > > > before could only mount it in an inner container.
> > > > > 
> > > > 
> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a 
> > > > userns
> > > > perspective.  Regular users on normal systems can already use 
> > > > ptmx,
> > > > and AFAICS basically all of the attack surface is already 
> > > > available
> > > > through the normal /dev/ptmx node.
> > > 
> > > My only real take is that there are a lot more places that you 
> > > need to
> > > tweak beyond devpts.  So this patch seemed lacking and boring.
> > > 
> > > Beyond that until I get the mount namespace sorted out things are 
> > > pretty
> > > much in a feature freeze because I can't multitask well enough to 
> > > do
> > > complicated patches and take feature patches.
> > > 
> > 
> > Eric, do you think you have time now to take a look at this patch?
> 
> I am much closer.  Escaping bind mounts is still not yet fixed but I
> have code that almost works.
> 
> My gut feel still says that two user namespaces one where your 0 is
> mapped to your uid and a second where your uid is identity mapped is 
> the
> preferrable configuration, and makes this patch unnecessary.

I don't really understand this. My usecase is that I want a desktop app
sandbox, it should run as the actual user that is running the graphical
session mapped to its real uid. In this namespace i want a /dev/pts so
that i can e.g. shell out to ssh and feed it a password on the tty
prompt or similar. And i don't want to bind-mount in the host /dev/pts,
because then the sandbox can read from the ttys of other apps.

Where does the second namespace enter into this? 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
> 
> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> > <ebiederm@xmission.com> wrote:
> > > Andy Lutomirski <luto@amacapital.net> writes:
> > > 
> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
> > > > alexl@redhat.com> wrote:
> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> > > > > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
> > > > > > > wrote:
> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
> > > > > > > > wrote:
> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski 
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > I don't think that this is correct.  That user can 
> > > > > > > > > > already create a
> > > > > > > > > > nested userns and map themselves as 0 inside it. 
> > > > > > > > > >  Then they can mount
> > > > > > > > > > devpts.
> > > > > > > > > 
> > > > > > > > > I don't mind if they create a container and control 
> > > > > > > > > the isolated ttys in
> > > > > > > > > that sub container in the VPS; that's fine.  I do 
> > > > > > > > > mind if they get
> > > > > > > > > access to the ttys in the VPS.
> > > > > > > > > 
> > > > > > > > > If you can convince me (and the rest of Linux) that 
> > > > > > > > > the tty subsystem
> > > > > > > > > should be mountable by an unprivileged user 
> > > > > > > > > generally, then what you
> > > > > > > > > propose is OK.
> > > > > > > > 
> > > > > > > > That is controlled by the general rights to mount 
> > > > > > > > stuff. I.e. unless you
> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be 
> > > > > > > > able to mount
> > > > > > > > devpts there. You can only do it in a subcontainer 
> > > > > > > > where you got
> > > > > > > > permissions to mount via using user namespaces.
> > > > > > > 
> > > > > > > OK let me try again.  Fine, if you want to speak 
> > > > > > > capabilities, you've
> > > > > > > given a non-root user an unexpected capability (the 
> > > > > > > capability of
> > > > > > > creating a ptmx device).  But you haven't used a 
> > > > > > > capability separation
> > > > > > > to do this, you've just hard coded it via a mount 
> > > > > > > parameter mechanism.
> > > > > > > 
> > > > > > > If you want to do this thing, do it properly, so it's 
> > > > > > > acceptable to the
> > > > > > > whole of Linux, not a special corner case for one 
> > > > > > > particular type of
> > > > > > > container.
> > > > > > > 
> > > > > > > Security breaches are created when people code in 
> > > > > > > special, little used,
> > > > > > > corner cases because they don't get as thoroughly tested 
> > > > > > > and inspected
> > > > > > > as generally applicable mechanisms.
> > > > > > > 
> > > > > > > What you want is to be able to use the tty subsystem as a 
> > > > > > > non root user:
> > > > > > > fine, but set that up globally, don't hide it in 
> > > > > > > containers so a lot
> > > > > > > fewer people care.
> > > > > > 
> > > > > > I tend to agree, and not just for the tty subsystem.  This 
> > > > > > is an
> > > > > > attack surface issue.  With unprivileged user namespaces, 
> > > > > > unprivileged
> > > > > > users can create mount namespaces (probably a good thing 
> > > > > > for bind
> > > > > > mounts, etc), network namespaces (reasonably safe by 
> > > > > > themselves),
> > > > > > network interfaces and iptables rules (scary), fresh
> > > > > > instances/superblocks of some filesystems (scariness 
> > > > > > depends on the fs
> > > > > > -- tmpfs is probably fine), and more.
> > > > > > 
> > > > > > I think we should have real controls for this, and this is 
> > > > > > mostly
> > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
> > > > > > prevents devpts
> > > > > > from being mountable isn't a real control, though.
> > > 
> > > I thought the controls for limiting how much of the userspace API
> > > an application could use were called seccomp and seccomp2.
> > > 
> > > Do we need something like a PAM module so that we can set up 
> > > these
> > > controls during login?
> > > 
> > > > > I'm honestly surprised that non-root is allowed to mount 
> > > > > things in
> > > > > general with user namespaces. This was long disabled use for 
> > > > > non-root in
> > > > > Fedora, but it is now enabled.
> > > > > 
> > > > > For instance, using loopback mounted files you could probably 
> > > > > attack
> > > > > some of the less well tested filesystem implementations by 
> > > > > feeding them
> > > > > fuzzed data.
> > > > > 
> > > > 
> > > > You actually can't do that right now.  Filesystems have to opt 
> > > > in to
> > > > being mounted in unprivileged user namespaces, and no 
> > > > filesystems with
> > > > backing stores have opted in.  devpts has, but it's buggy 
> > > > without this
> > > > patch IMO.
> > > 
> > > Arguably you should use two user namespaces.  The first to do 
> > > what you
> > > want to as root the second to run as the uid you want to run as.
> > > 
> > > > > Anyway, I don't see how this affects devpts though. If you're 
> > > > > running in
> > > > > a container (or uncontained), as a regular users with no 
> > > > > mount
> > > > > capabilities you can already mount a devpts filesystem if you 
> > > > > create a
> > > > > subbcontainer with user namespaces and map your uid to 0 in 
> > > > > the
> > > > > subcontainer. Then you get a new ptmx device that you can do 
> > > > > whatever
> > > > > you want with. The mount option would let you do the same, 
> > > > > except be
> > > > > your regular uid in the subcontainer.
> > > > > 
> > > > > The only difference outside of the subcontainer is that if 
> > > > > the outer
> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN 
> > > > > rights in
> > > > > that container. Then he can mount devpts in the outer 
> > > > > container where he
> > > > > before could only mount it in an inner container.
> > > > > 
> > > > 
> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a 
> > > > userns
> > > > perspective.  Regular users on normal systems can already use 
> > > > ptmx,
> > > > and AFAICS basically all of the attack surface is already 
> > > > available
> > > > through the normal /dev/ptmx node.
> > > 
> > > My only real take is that there are a lot more places that you 
> > > need to
> > > tweak beyond devpts.  So this patch seemed lacking and boring.
> > > 
> > > Beyond that until I get the mount namespace sorted out things are 
> > > pretty
> > > much in a feature freeze because I can't multitask well enough to 
> > > do
> > > complicated patches and take feature patches.
> > > 
> > 
> > Eric, do you think you have time now to take a look at this patch?
> 
> I am much closer.  Escaping bind mounts is still not yet fixed but I
> have code that almost works.
> 
> My gut feel still says that two user namespaces one where your 0 is
> mapped to your uid and a second where your uid is identity mapped is 
> the
> preferrable configuration, and makes this patch unnecessary.

I don't really understand this. My usecase is that I want a desktop app
sandbox, it should run as the actual user that is running the graphical
session mapped to its real uid. In this namespace i want a /dev/pts so
that i can e.g. shell out to ssh and feed it a password on the tty
prompt or similar. And i don't want to bind-mount in the host /dev/pts,
because then the sandbox can read from the ttys of other apps.

Where does the second namespace enter into this? 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>> 
>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>> > > 
>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>> > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
>> > > > > > > wrote:
>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
>> > > > > > > > wrote:
>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski 
>> > > > > > > > > wrote:
>> > > > > > > > > > 
>> > > > > > > > > > I don't think that this is correct.  That user can 
>> > > > > > > > > > already create a
>> > > > > > > > > > nested userns and map themselves as 0 inside it. 
>> > > > > > > > > >  Then they can mount
>> > > > > > > > > > devpts.
>> > > > > > > > > 
>> > > > > > > > > I don't mind if they create a container and control 
>> > > > > > > > > the isolated ttys in
>> > > > > > > > > that sub container in the VPS; that's fine.  I do 
>> > > > > > > > > mind if they get
>> > > > > > > > > access to the ttys in the VPS.
>> > > > > > > > > 
>> > > > > > > > > If you can convince me (and the rest of Linux) that 
>> > > > > > > > > the tty subsystem
>> > > > > > > > > should be mountable by an unprivileged user 
>> > > > > > > > > generally, then what you
>> > > > > > > > > propose is OK.
>> > > > > > > > 
>> > > > > > > > That is controlled by the general rights to mount 
>> > > > > > > > stuff. I.e. unless you
>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be 
>> > > > > > > > able to mount
>> > > > > > > > devpts there. You can only do it in a subcontainer 
>> > > > > > > > where you got
>> > > > > > > > permissions to mount via using user namespaces.
>> > > > > > > 
>> > > > > > > OK let me try again.  Fine, if you want to speak 
>> > > > > > > capabilities, you've
>> > > > > > > given a non-root user an unexpected capability (the 
>> > > > > > > capability of
>> > > > > > > creating a ptmx device).  But you haven't used a 
>> > > > > > > capability separation
>> > > > > > > to do this, you've just hard coded it via a mount 
>> > > > > > > parameter mechanism.
>> > > > > > > 
>> > > > > > > If you want to do this thing, do it properly, so it's 
>> > > > > > > acceptable to the
>> > > > > > > whole of Linux, not a special corner case for one 
>> > > > > > > particular type of
>> > > > > > > container.
>> > > > > > > 
>> > > > > > > Security breaches are created when people code in 
>> > > > > > > special, little used,
>> > > > > > > corner cases because they don't get as thoroughly tested 
>> > > > > > > and inspected
>> > > > > > > as generally applicable mechanisms.
>> > > > > > > 
>> > > > > > > What you want is to be able to use the tty subsystem as a 
>> > > > > > > non root user:
>> > > > > > > fine, but set that up globally, don't hide it in 
>> > > > > > > containers so a lot
>> > > > > > > fewer people care.
>> > > > > > 
>> > > > > > I tend to agree, and not just for the tty subsystem.  This 
>> > > > > > is an
>> > > > > > attack surface issue.  With unprivileged user namespaces, 
>> > > > > > unprivileged
>> > > > > > users can create mount namespaces (probably a good thing 
>> > > > > > for bind
>> > > > > > mounts, etc), network namespaces (reasonably safe by 
>> > > > > > themselves),
>> > > > > > network interfaces and iptables rules (scary), fresh
>> > > > > > instances/superblocks of some filesystems (scariness 
>> > > > > > depends on the fs
>> > > > > > -- tmpfs is probably fine), and more.
>> > > > > > 
>> > > > > > I think we should have real controls for this, and this is 
>> > > > > > mostly
>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
>> > > > > > prevents devpts
>> > > > > > from being mountable isn't a real control, though.
>> > > 
>> > > I thought the controls for limiting how much of the userspace API
>> > > an application could use were called seccomp and seccomp2.
>> > > 
>> > > Do we need something like a PAM module so that we can set up 
>> > > these
>> > > controls during login?
>> > > 
>> > > > > I'm honestly surprised that non-root is allowed to mount 
>> > > > > things in
>> > > > > general with user namespaces. This was long disabled use for 
>> > > > > non-root in
>> > > > > Fedora, but it is now enabled.
>> > > > > 
>> > > > > For instance, using loopback mounted files you could probably 
>> > > > > attack
>> > > > > some of the less well tested filesystem implementations by 
>> > > > > feeding them
>> > > > > fuzzed data.
>> > > > > 
>> > > > 
>> > > > You actually can't do that right now.  Filesystems have to opt 
>> > > > in to
>> > > > being mounted in unprivileged user namespaces, and no 
>> > > > filesystems with
>> > > > backing stores have opted in.  devpts has, but it's buggy 
>> > > > without this
>> > > > patch IMO.
>> > > 
>> > > Arguably you should use two user namespaces.  The first to do 
>> > > what you
>> > > want to as root the second to run as the uid you want to run as.
>> > > 
>> > > > > Anyway, I don't see how this affects devpts though. If you're 
>> > > > > running in
>> > > > > a container (or uncontained), as a regular users with no 
>> > > > > mount
>> > > > > capabilities you can already mount a devpts filesystem if you 
>> > > > > create a
>> > > > > subbcontainer with user namespaces and map your uid to 0 in 
>> > > > > the
>> > > > > subcontainer. Then you get a new ptmx device that you can do 
>> > > > > whatever
>> > > > > you want with. The mount option would let you do the same, 
>> > > > > except be
>> > > > > your regular uid in the subcontainer.
>> > > > > 
>> > > > > The only difference outside of the subcontainer is that if 
>> > > > > the outer
>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN 
>> > > > > rights in
>> > > > > that container. Then he can mount devpts in the outer 
>> > > > > container where he
>> > > > > before could only mount it in an inner container.
>> > > > > 
>> > > > 
>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a 
>> > > > userns
>> > > > perspective.  Regular users on normal systems can already use 
>> > > > ptmx,
>> > > > and AFAICS basically all of the attack surface is already 
>> > > > available
>> > > > through the normal /dev/ptmx node.
>> > > 
>> > > My only real take is that there are a lot more places that you 
>> > > need to
>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>> > > 
>> > > Beyond that until I get the mount namespace sorted out things are 
>> > > pretty
>> > > much in a feature freeze because I can't multitask well enough to 
>> > > do
>> > > complicated patches and take feature patches.
>> > > 
>> > 
>> > Eric, do you think you have time now to take a look at this patch?
>> 
>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>> have code that almost works.
>> 
>> My gut feel still says that two user namespaces one where your 0 is
>> mapped to your uid and a second where your uid is identity mapped is 
>> the
>> preferrable configuration, and makes this patch unnecessary.
>
> I don't really understand this. My usecase is that I want a desktop app
> sandbox, it should run as the actual user that is running the graphical
> session mapped to its real uid. In this namespace i want a /dev/pts so
> that i can e.g. shell out to ssh and feed it a password on the tty
> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
> because then the sandbox can read from the ttys of other apps.
>
> Where does the second namespace enter into this? 

Step a.  Create create a user namespace where uid 0 is mapped to your
real uid, and set up your sandbox (aka mount /dev/pts and everything
else).

Step b.  Create a nested user namespace where your uid is identity
mapped and run your desktop application.  You can even drop all caps in
your namespace.

Or basically:
    unshare(CLONE_NEWUSER)
    
    map 0 to real_uid
    set things up.
    
    unshare(CLONE_NEWUSER)
    map real_uid to 0 (Because I am assuming we are
                      single threaded in the nested context)
    
    drop caps
    exec /path/to/my/sandboxed/application

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Alexander Larsson <alexl@redhat.com> writes:

> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>> 
>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>> > <ebiederm@xmission.com> wrote:
>> > > Andy Lutomirski <luto@amacapital.net> writes:
>> > > 
>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>> > > > alexl@redhat.com> wrote:
>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> > > > > > <James.Bottomley@hansenpartnership.com> wrote:
>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
>> > > > > > > wrote:
>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
>> > > > > > > > wrote:
>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski 
>> > > > > > > > > wrote:
>> > > > > > > > > > 
>> > > > > > > > > > I don't think that this is correct.  That user can 
>> > > > > > > > > > already create a
>> > > > > > > > > > nested userns and map themselves as 0 inside it. 
>> > > > > > > > > >  Then they can mount
>> > > > > > > > > > devpts.
>> > > > > > > > > 
>> > > > > > > > > I don't mind if they create a container and control 
>> > > > > > > > > the isolated ttys in
>> > > > > > > > > that sub container in the VPS; that's fine.  I do 
>> > > > > > > > > mind if they get
>> > > > > > > > > access to the ttys in the VPS.
>> > > > > > > > > 
>> > > > > > > > > If you can convince me (and the rest of Linux) that 
>> > > > > > > > > the tty subsystem
>> > > > > > > > > should be mountable by an unprivileged user 
>> > > > > > > > > generally, then what you
>> > > > > > > > > propose is OK.
>> > > > > > > > 
>> > > > > > > > That is controlled by the general rights to mount 
>> > > > > > > > stuff. I.e. unless you
>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be 
>> > > > > > > > able to mount
>> > > > > > > > devpts there. You can only do it in a subcontainer 
>> > > > > > > > where you got
>> > > > > > > > permissions to mount via using user namespaces.
>> > > > > > > 
>> > > > > > > OK let me try again.  Fine, if you want to speak 
>> > > > > > > capabilities, you've
>> > > > > > > given a non-root user an unexpected capability (the 
>> > > > > > > capability of
>> > > > > > > creating a ptmx device).  But you haven't used a 
>> > > > > > > capability separation
>> > > > > > > to do this, you've just hard coded it via a mount 
>> > > > > > > parameter mechanism.
>> > > > > > > 
>> > > > > > > If you want to do this thing, do it properly, so it's 
>> > > > > > > acceptable to the
>> > > > > > > whole of Linux, not a special corner case for one 
>> > > > > > > particular type of
>> > > > > > > container.
>> > > > > > > 
>> > > > > > > Security breaches are created when people code in 
>> > > > > > > special, little used,
>> > > > > > > corner cases because they don't get as thoroughly tested 
>> > > > > > > and inspected
>> > > > > > > as generally applicable mechanisms.
>> > > > > > > 
>> > > > > > > What you want is to be able to use the tty subsystem as a 
>> > > > > > > non root user:
>> > > > > > > fine, but set that up globally, don't hide it in 
>> > > > > > > containers so a lot
>> > > > > > > fewer people care.
>> > > > > > 
>> > > > > > I tend to agree, and not just for the tty subsystem.  This 
>> > > > > > is an
>> > > > > > attack surface issue.  With unprivileged user namespaces, 
>> > > > > > unprivileged
>> > > > > > users can create mount namespaces (probably a good thing 
>> > > > > > for bind
>> > > > > > mounts, etc), network namespaces (reasonably safe by 
>> > > > > > themselves),
>> > > > > > network interfaces and iptables rules (scary), fresh
>> > > > > > instances/superblocks of some filesystems (scariness 
>> > > > > > depends on the fs
>> > > > > > -- tmpfs is probably fine), and more.
>> > > > > > 
>> > > > > > I think we should have real controls for this, and this is 
>> > > > > > mostly
>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
>> > > > > > prevents devpts
>> > > > > > from being mountable isn't a real control, though.
>> > > 
>> > > I thought the controls for limiting how much of the userspace API
>> > > an application could use were called seccomp and seccomp2.
>> > > 
>> > > Do we need something like a PAM module so that we can set up 
>> > > these
>> > > controls during login?
>> > > 
>> > > > > I'm honestly surprised that non-root is allowed to mount 
>> > > > > things in
>> > > > > general with user namespaces. This was long disabled use for 
>> > > > > non-root in
>> > > > > Fedora, but it is now enabled.
>> > > > > 
>> > > > > For instance, using loopback mounted files you could probably 
>> > > > > attack
>> > > > > some of the less well tested filesystem implementations by 
>> > > > > feeding them
>> > > > > fuzzed data.
>> > > > > 
>> > > > 
>> > > > You actually can't do that right now.  Filesystems have to opt 
>> > > > in to
>> > > > being mounted in unprivileged user namespaces, and no 
>> > > > filesystems with
>> > > > backing stores have opted in.  devpts has, but it's buggy 
>> > > > without this
>> > > > patch IMO.
>> > > 
>> > > Arguably you should use two user namespaces.  The first to do 
>> > > what you
>> > > want to as root the second to run as the uid you want to run as.
>> > > 
>> > > > > Anyway, I don't see how this affects devpts though. If you're 
>> > > > > running in
>> > > > > a container (or uncontained), as a regular users with no 
>> > > > > mount
>> > > > > capabilities you can already mount a devpts filesystem if you 
>> > > > > create a
>> > > > > subbcontainer with user namespaces and map your uid to 0 in 
>> > > > > the
>> > > > > subcontainer. Then you get a new ptmx device that you can do 
>> > > > > whatever
>> > > > > you want with. The mount option would let you do the same, 
>> > > > > except be
>> > > > > your regular uid in the subcontainer.
>> > > > > 
>> > > > > The only difference outside of the subcontainer is that if 
>> > > > > the outer
>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN 
>> > > > > rights in
>> > > > > that container. Then he can mount devpts in the outer 
>> > > > > container where he
>> > > > > before could only mount it in an inner container.
>> > > > > 
>> > > > 
>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a 
>> > > > userns
>> > > > perspective.  Regular users on normal systems can already use 
>> > > > ptmx,
>> > > > and AFAICS basically all of the attack surface is already 
>> > > > available
>> > > > through the normal /dev/ptmx node.
>> > > 
>> > > My only real take is that there are a lot more places that you 
>> > > need to
>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>> > > 
>> > > Beyond that until I get the mount namespace sorted out things are 
>> > > pretty
>> > > much in a feature freeze because I can't multitask well enough to 
>> > > do
>> > > complicated patches and take feature patches.
>> > > 
>> > 
>> > Eric, do you think you have time now to take a look at this patch?
>> 
>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>> have code that almost works.
>> 
>> My gut feel still says that two user namespaces one where your 0 is
>> mapped to your uid and a second where your uid is identity mapped is 
>> the
>> preferrable configuration, and makes this patch unnecessary.
>
> I don't really understand this. My usecase is that I want a desktop app
> sandbox, it should run as the actual user that is running the graphical
> session mapped to its real uid. In this namespace i want a /dev/pts so
> that i can e.g. shell out to ssh and feed it a password on the tty
> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
> because then the sandbox can read from the ttys of other apps.
>
> Where does the second namespace enter into this? 

Step a.  Create create a user namespace where uid 0 is mapped to your
real uid, and set up your sandbox (aka mount /dev/pts and everything
else).

Step b.  Create a nested user namespace where your uid is identity
mapped and run your desktop application.  You can even drop all caps in
your namespace.

Or basically:
    unshare(CLONE_NEWUSER)
    
    map 0 to real_uid
    set things up.
    
    unshare(CLONE_NEWUSER)
    map real_uid to 0 (Because I am assuming we are
                      single threaded in the nested context)
    
    drop caps
    exec /path/to/my/sandboxed/application

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>
>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>> > >
>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>> > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>> > > > > > > wrote:
>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>> > > > > > > > wrote:
>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>> > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > I don't think that this is correct.  That user can
>> > > > > > > > > > already create a
>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>> > > > > > > > > >  Then they can mount
>> > > > > > > > > > devpts.
>> > > > > > > > >
>> > > > > > > > > I don't mind if they create a container and control
>> > > > > > > > > the isolated ttys in
>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>> > > > > > > > > mind if they get
>> > > > > > > > > access to the ttys in the VPS.
>> > > > > > > > >
>> > > > > > > > > If you can convince me (and the rest of Linux) that
>> > > > > > > > > the tty subsystem
>> > > > > > > > > should be mountable by an unprivileged user
>> > > > > > > > > generally, then what you
>> > > > > > > > > propose is OK.
>> > > > > > > >
>> > > > > > > > That is controlled by the general rights to mount
>> > > > > > > > stuff. I.e. unless you
>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>> > > > > > > > able to mount
>> > > > > > > > devpts there. You can only do it in a subcontainer
>> > > > > > > > where you got
>> > > > > > > > permissions to mount via using user namespaces.
>> > > > > > >
>> > > > > > > OK let me try again.  Fine, if you want to speak
>> > > > > > > capabilities, you've
>> > > > > > > given a non-root user an unexpected capability (the
>> > > > > > > capability of
>> > > > > > > creating a ptmx device).  But you haven't used a
>> > > > > > > capability separation
>> > > > > > > to do this, you've just hard coded it via a mount
>> > > > > > > parameter mechanism.
>> > > > > > >
>> > > > > > > If you want to do this thing, do it properly, so it's
>> > > > > > > acceptable to the
>> > > > > > > whole of Linux, not a special corner case for one
>> > > > > > > particular type of
>> > > > > > > container.
>> > > > > > >
>> > > > > > > Security breaches are created when people code in
>> > > > > > > special, little used,
>> > > > > > > corner cases because they don't get as thoroughly tested
>> > > > > > > and inspected
>> > > > > > > as generally applicable mechanisms.
>> > > > > > >
>> > > > > > > What you want is to be able to use the tty subsystem as a
>> > > > > > > non root user:
>> > > > > > > fine, but set that up globally, don't hide it in
>> > > > > > > containers so a lot
>> > > > > > > fewer people care.
>> > > > > >
>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>> > > > > > is an
>> > > > > > attack surface issue.  With unprivileged user namespaces,
>> > > > > > unprivileged
>> > > > > > users can create mount namespaces (probably a good thing
>> > > > > > for bind
>> > > > > > mounts, etc), network namespaces (reasonably safe by
>> > > > > > themselves),
>> > > > > > network interfaces and iptables rules (scary), fresh
>> > > > > > instances/superblocks of some filesystems (scariness
>> > > > > > depends on the fs
>> > > > > > -- tmpfs is probably fine), and more.
>> > > > > >
>> > > > > > I think we should have real controls for this, and this is
>> > > > > > mostly
>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>> > > > > > prevents devpts
>> > > > > > from being mountable isn't a real control, though.
>> > >
>> > > I thought the controls for limiting how much of the userspace API
>> > > an application could use were called seccomp and seccomp2.
>> > >
>> > > Do we need something like a PAM module so that we can set up
>> > > these
>> > > controls during login?
>> > >
>> > > > > I'm honestly surprised that non-root is allowed to mount
>> > > > > things in
>> > > > > general with user namespaces. This was long disabled use for
>> > > > > non-root in
>> > > > > Fedora, but it is now enabled.
>> > > > >
>> > > > > For instance, using loopback mounted files you could probably
>> > > > > attack
>> > > > > some of the less well tested filesystem implementations by
>> > > > > feeding them
>> > > > > fuzzed data.
>> > > > >
>> > > >
>> > > > You actually can't do that right now.  Filesystems have to opt
>> > > > in to
>> > > > being mounted in unprivileged user namespaces, and no
>> > > > filesystems with
>> > > > backing stores have opted in.  devpts has, but it's buggy
>> > > > without this
>> > > > patch IMO.
>> > >
>> > > Arguably you should use two user namespaces.  The first to do
>> > > what you
>> > > want to as root the second to run as the uid you want to run as.
>> > >
>> > > > > Anyway, I don't see how this affects devpts though. If you're
>> > > > > running in
>> > > > > a container (or uncontained), as a regular users with no
>> > > > > mount
>> > > > > capabilities you can already mount a devpts filesystem if you
>> > > > > create a
>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>> > > > > the
>> > > > > subcontainer. Then you get a new ptmx device that you can do
>> > > > > whatever
>> > > > > you want with. The mount option would let you do the same,
>> > > > > except be
>> > > > > your regular uid in the subcontainer.
>> > > > >
>> > > > > The only difference outside of the subcontainer is that if
>> > > > > the outer
>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>> > > > > rights in
>> > > > > that container. Then he can mount devpts in the outer
>> > > > > container where he
>> > > > > before could only mount it in an inner container.
>> > > > >
>> > > >
>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>> > > > userns
>> > > > perspective.  Regular users on normal systems can already use
>> > > > ptmx,
>> > > > and AFAICS basically all of the attack surface is already
>> > > > available
>> > > > through the normal /dev/ptmx node.
>> > >
>> > > My only real take is that there are a lot more places that you
>> > > need to
>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>> > >
>> > > Beyond that until I get the mount namespace sorted out things are
>> > > pretty
>> > > much in a feature freeze because I can't multitask well enough to
>> > > do
>> > > complicated patches and take feature patches.
>> > >
>> >
>> > Eric, do you think you have time now to take a look at this patch?
>>
>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>> have code that almost works.
>>
>> My gut feel still says that two user namespaces one where your 0 is
>> mapped to your uid and a second where your uid is identity mapped is
>> the
>> preferrable configuration, and makes this patch unnecessary.
>
> I don't really understand this. My usecase is that I want a desktop app
> sandbox, it should run as the actual user that is running the graphical
> session mapped to its real uid. In this namespace i want a /dev/pts so
> that i can e.g. shell out to ssh and feed it a password on the tty
> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
> because then the sandbox can read from the ttys of other apps.
>
> Where does the second namespace enter into this?
>

I think Eric is suggesting making a user namespace that maps your uid
as 0, then making a mount namespace and mounting devpts, then making
*another* user namespace that maps your uid (seen as 0) back to
whatever nonzero number you want.

That would probably work, but I think it's really ugly.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl@redhat.com> wrote:
> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>> > <ebiederm@xmission.com> wrote:
>> > > Andy Lutomirski <luto@amacapital.net> writes:
>> > >
>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>> > > > alexl@redhat.com> wrote:
>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>> > > > > > <James.Bottomley@hansenpartnership.com> wrote:
>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>> > > > > > > wrote:
>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>> > > > > > > > wrote:
>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>> > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > I don't think that this is correct.  That user can
>> > > > > > > > > > already create a
>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>> > > > > > > > > >  Then they can mount
>> > > > > > > > > > devpts.
>> > > > > > > > >
>> > > > > > > > > I don't mind if they create a container and control
>> > > > > > > > > the isolated ttys in
>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>> > > > > > > > > mind if they get
>> > > > > > > > > access to the ttys in the VPS.
>> > > > > > > > >
>> > > > > > > > > If you can convince me (and the rest of Linux) that
>> > > > > > > > > the tty subsystem
>> > > > > > > > > should be mountable by an unprivileged user
>> > > > > > > > > generally, then what you
>> > > > > > > > > propose is OK.
>> > > > > > > >
>> > > > > > > > That is controlled by the general rights to mount
>> > > > > > > > stuff. I.e. unless you
>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>> > > > > > > > able to mount
>> > > > > > > > devpts there. You can only do it in a subcontainer
>> > > > > > > > where you got
>> > > > > > > > permissions to mount via using user namespaces.
>> > > > > > >
>> > > > > > > OK let me try again.  Fine, if you want to speak
>> > > > > > > capabilities, you've
>> > > > > > > given a non-root user an unexpected capability (the
>> > > > > > > capability of
>> > > > > > > creating a ptmx device).  But you haven't used a
>> > > > > > > capability separation
>> > > > > > > to do this, you've just hard coded it via a mount
>> > > > > > > parameter mechanism.
>> > > > > > >
>> > > > > > > If you want to do this thing, do it properly, so it's
>> > > > > > > acceptable to the
>> > > > > > > whole of Linux, not a special corner case for one
>> > > > > > > particular type of
>> > > > > > > container.
>> > > > > > >
>> > > > > > > Security breaches are created when people code in
>> > > > > > > special, little used,
>> > > > > > > corner cases because they don't get as thoroughly tested
>> > > > > > > and inspected
>> > > > > > > as generally applicable mechanisms.
>> > > > > > >
>> > > > > > > What you want is to be able to use the tty subsystem as a
>> > > > > > > non root user:
>> > > > > > > fine, but set that up globally, don't hide it in
>> > > > > > > containers so a lot
>> > > > > > > fewer people care.
>> > > > > >
>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>> > > > > > is an
>> > > > > > attack surface issue.  With unprivileged user namespaces,
>> > > > > > unprivileged
>> > > > > > users can create mount namespaces (probably a good thing
>> > > > > > for bind
>> > > > > > mounts, etc), network namespaces (reasonably safe by
>> > > > > > themselves),
>> > > > > > network interfaces and iptables rules (scary), fresh
>> > > > > > instances/superblocks of some filesystems (scariness
>> > > > > > depends on the fs
>> > > > > > -- tmpfs is probably fine), and more.
>> > > > > >
>> > > > > > I think we should have real controls for this, and this is
>> > > > > > mostly
>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>> > > > > > prevents devpts
>> > > > > > from being mountable isn't a real control, though.
>> > >
>> > > I thought the controls for limiting how much of the userspace API
>> > > an application could use were called seccomp and seccomp2.
>> > >
>> > > Do we need something like a PAM module so that we can set up
>> > > these
>> > > controls during login?
>> > >
>> > > > > I'm honestly surprised that non-root is allowed to mount
>> > > > > things in
>> > > > > general with user namespaces. This was long disabled use for
>> > > > > non-root in
>> > > > > Fedora, but it is now enabled.
>> > > > >
>> > > > > For instance, using loopback mounted files you could probably
>> > > > > attack
>> > > > > some of the less well tested filesystem implementations by
>> > > > > feeding them
>> > > > > fuzzed data.
>> > > > >
>> > > >
>> > > > You actually can't do that right now.  Filesystems have to opt
>> > > > in to
>> > > > being mounted in unprivileged user namespaces, and no
>> > > > filesystems with
>> > > > backing stores have opted in.  devpts has, but it's buggy
>> > > > without this
>> > > > patch IMO.
>> > >
>> > > Arguably you should use two user namespaces.  The first to do
>> > > what you
>> > > want to as root the second to run as the uid you want to run as.
>> > >
>> > > > > Anyway, I don't see how this affects devpts though. If you're
>> > > > > running in
>> > > > > a container (or uncontained), as a regular users with no
>> > > > > mount
>> > > > > capabilities you can already mount a devpts filesystem if you
>> > > > > create a
>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>> > > > > the
>> > > > > subcontainer. Then you get a new ptmx device that you can do
>> > > > > whatever
>> > > > > you want with. The mount option would let you do the same,
>> > > > > except be
>> > > > > your regular uid in the subcontainer.
>> > > > >
>> > > > > The only difference outside of the subcontainer is that if
>> > > > > the outer
>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>> > > > > rights in
>> > > > > that container. Then he can mount devpts in the outer
>> > > > > container where he
>> > > > > before could only mount it in an inner container.
>> > > > >
>> > > >
>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>> > > > userns
>> > > > perspective.  Regular users on normal systems can already use
>> > > > ptmx,
>> > > > and AFAICS basically all of the attack surface is already
>> > > > available
>> > > > through the normal /dev/ptmx node.
>> > >
>> > > My only real take is that there are a lot more places that you
>> > > need to
>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>> > >
>> > > Beyond that until I get the mount namespace sorted out things are
>> > > pretty
>> > > much in a feature freeze because I can't multitask well enough to
>> > > do
>> > > complicated patches and take feature patches.
>> > >
>> >
>> > Eric, do you think you have time now to take a look at this patch?
>>
>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>> have code that almost works.
>>
>> My gut feel still says that two user namespaces one where your 0 is
>> mapped to your uid and a second where your uid is identity mapped is
>> the
>> preferrable configuration, and makes this patch unnecessary.
>
> I don't really understand this. My usecase is that I want a desktop app
> sandbox, it should run as the actual user that is running the graphical
> session mapped to its real uid. In this namespace i want a /dev/pts so
> that i can e.g. shell out to ssh and feed it a password on the tty
> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
> because then the sandbox can read from the ttys of other apps.
>
> Where does the second namespace enter into this?
>

I think Eric is suggesting making a user namespace that maps your uid
as 0, then making a mount namespace and mounting devpts, then making
*another* user namespace that maps your uid (seen as 0) back to
whatever nonzero number you want.

That would probably work, but I think it's really ugly.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
> Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> 
> > On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> > > 
> > > > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> > > > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> > > > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> > > > > 
> > > > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
> > > > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> > > > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> > > > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
> > > > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
> > > > > > > > > wrote:
> > > > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy 
> > > > > > > > > > > Lutomirski 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think that this is correct.  That user 
> > > > > > > > > > > > can 
> > > > > > > > > > > > already create a
> > > > > > > > > > > > nested userns and map themselves as 0 inside 
> > > > > > > > > > > > it. 
> > > > > > > > > > > >  Then they can mount
> > > > > > > > > > > > devpts.
> > > > > > > > > > > 
> > > > > > > > > > > I don't mind if they create a container and 
> > > > > > > > > > > control 
> > > > > > > > > > > the isolated ttys in
> > > > > > > > > > > that sub container in the VPS; that's fine.  I do 
> > > > > > > > > > > 
> > > > > > > > > > > mind if they get
> > > > > > > > > > > access to the ttys in the VPS.
> > > > > > > > > > > 
> > > > > > > > > > > If you can convince me (and the rest of Linux) 
> > > > > > > > > > > that 
> > > > > > > > > > > the tty subsystem
> > > > > > > > > > > should be mountable by an unprivileged user 
> > > > > > > > > > > generally, then what you
> > > > > > > > > > > propose is OK.
> > > > > > > > > > 
> > > > > > > > > > That is controlled by the general rights to mount 
> > > > > > > > > > stuff. I.e. unless you
> > > > > > > > > > have CAP_SYS_ADMIN in the VPS container you will 
> > > > > > > > > > not be 
> > > > > > > > > > able to mount
> > > > > > > > > > devpts there. You can only do it in a subcontainer 
> > > > > > > > > > where you got
> > > > > > > > > > permissions to mount via using user namespaces.
> > > > > > > > > 
> > > > > > > > > OK let me try again.  Fine, if you want to speak 
> > > > > > > > > capabilities, you've
> > > > > > > > > given a non-root user an unexpected capability (the 
> > > > > > > > > capability of
> > > > > > > > > creating a ptmx device).  But you haven't used a 
> > > > > > > > > capability separation
> > > > > > > > > to do this, you've just hard coded it via a mount 
> > > > > > > > > parameter mechanism.
> > > > > > > > > 
> > > > > > > > > If you want to do this thing, do it properly, so it's 
> > > > > > > > > 
> > > > > > > > > acceptable to the
> > > > > > > > > whole of Linux, not a special corner case for one 
> > > > > > > > > particular type of
> > > > > > > > > container.
> > > > > > > > > 
> > > > > > > > > Security breaches are created when people code in 
> > > > > > > > > special, little used,
> > > > > > > > > corner cases because they don't get as thoroughly 
> > > > > > > > > tested 
> > > > > > > > > and inspected
> > > > > > > > > as generally applicable mechanisms.
> > > > > > > > > 
> > > > > > > > > What you want is to be able to use the tty subsystem 
> > > > > > > > > as a 
> > > > > > > > > non root user:
> > > > > > > > > fine, but set that up globally, don't hide it in 
> > > > > > > > > containers so a lot
> > > > > > > > > fewer people care.
> > > > > > > > 
> > > > > > > > I tend to agree, and not just for the tty subsystem. 
> > > > > > > >  This 
> > > > > > > > is an
> > > > > > > > attack surface issue.  With unprivileged user 
> > > > > > > > namespaces, 
> > > > > > > > unprivileged
> > > > > > > > users can create mount namespaces (probably a good 
> > > > > > > > thing 
> > > > > > > > for bind
> > > > > > > > mounts, etc), network namespaces (reasonably safe by 
> > > > > > > > themselves),
> > > > > > > > network interfaces and iptables rules (scary), fresh
> > > > > > > > instances/superblocks of some filesystems (scariness 
> > > > > > > > depends on the fs
> > > > > > > > -- tmpfs is probably fine), and more.
> > > > > > > > 
> > > > > > > > I think we should have real controls for this, and this 
> > > > > > > > is 
> > > > > > > > mostly
> > > > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
> > > > > > > > prevents devpts
> > > > > > > > from being mountable isn't a real control, though.
> > > > > 
> > > > > I thought the controls for limiting how much of the userspace 
> > > > > API
> > > > > an application could use were called seccomp and seccomp2.
> > > > > 
> > > > > Do we need something like a PAM module so that we can set up 
> > > > > these
> > > > > controls during login?
> > > > > 
> > > > > > > I'm honestly surprised that non-root is allowed to mount 
> > > > > > > things in
> > > > > > > general with user namespaces. This was long disabled use 
> > > > > > > for 
> > > > > > > non-root in
> > > > > > > Fedora, but it is now enabled.
> > > > > > > 
> > > > > > > For instance, using loopback mounted files you could 
> > > > > > > probably 
> > > > > > > attack
> > > > > > > some of the less well tested filesystem implementations 
> > > > > > > by 
> > > > > > > feeding them
> > > > > > > fuzzed data.
> > > > > > > 
> > > > > > 
> > > > > > You actually can't do that right now.  Filesystems have to 
> > > > > > opt 
> > > > > > in to
> > > > > > being mounted in unprivileged user namespaces, and no 
> > > > > > filesystems with
> > > > > > backing stores have opted in.  devpts has, but it's buggy 
> > > > > > without this
> > > > > > patch IMO.
> > > > > 
> > > > > Arguably you should use two user namespaces.  The first to do 
> > > > > 
> > > > > what you
> > > > > want to as root the second to run as the uid you want to run 
> > > > > as.
> > > > > 
> > > > > > > Anyway, I don't see how this affects devpts though. If 
> > > > > > > you're 
> > > > > > > running in
> > > > > > > a container (or uncontained), as a regular users with no 
> > > > > > > mount
> > > > > > > capabilities you can already mount a devpts filesystem if 
> > > > > > > you 
> > > > > > > create a
> > > > > > > subbcontainer with user namespaces and map your uid to 0 
> > > > > > > in 
> > > > > > > the
> > > > > > > subcontainer. Then you get a new ptmx device that you can 
> > > > > > > do 
> > > > > > > whatever
> > > > > > > you want with. The mount option would let you do the 
> > > > > > > same, 
> > > > > > > except be
> > > > > > > your regular uid in the subcontainer.
> > > > > > > 
> > > > > > > The only difference outside of the subcontainer is that 
> > > > > > > if 
> > > > > > > the outer
> > > > > > > container has no uid 0 mapped, yet the user has 
> > > > > > > CAP_SYSADMIN 
> > > > > > > rights in
> > > > > > > that container. Then he can mount devpts in the outer 
> > > > > > > container where he
> > > > > > > before could only mount it in an inner container.
> > > > > > > 
> > > > > > 
> > > > > > Agreed.  Also, devpts doesn't seem scary at all to me from 
> > > > > > a 
> > > > > > userns
> > > > > > perspective.  Regular users on normal systems can already 
> > > > > > use 
> > > > > > ptmx,
> > > > > > and AFAICS basically all of the attack surface is already 
> > > > > > available
> > > > > > through the normal /dev/ptmx node.
> > > > > 
> > > > > My only real take is that there are a lot more places that 
> > > > > you 
> > > > > need to
> > > > > tweak beyond devpts.  So this patch seemed lacking and 
> > > > > boring.
> > > > > 
> > > > > Beyond that until I get the mount namespace sorted out things 
> > > > > are 
> > > > > pretty
> > > > > much in a feature freeze because I can't multitask well 
> > > > > enough to 
> > > > > do
> > > > > complicated patches and take feature patches.
> > > > > 
> > > > 
> > > > Eric, do you think you have time now to take a look at this 
> > > > patch?
> > > 
> > > I am much closer.  Escaping bind mounts is still not yet fixed 
> > > but I
> > > have code that almost works.
> > > 
> > > My gut feel still says that two user namespaces one where your 0 
> > > is
> > > mapped to your uid and a second where your uid is identity mapped 
> > > is 
> > > the
> > > preferrable configuration, and makes this patch unnecessary.
> > 
> > I don't really understand this. My usecase is that I want a desktop 
> > app
> > sandbox, it should run as the actual user that is running the 
> > graphical
> > session mapped to its real uid. In this namespace i want a /dev/pts 
> > so
> > that i can e.g. shell out to ssh and feed it a password on the tty
> > prompt or similar. And i don't want to bind-mount in the host 
> > /dev/pts,
> > because then the sandbox can read from the ttys of other apps.
> > 
> > Where does the second namespace enter into this? 
> 
> Step a.  Create create a user namespace where uid 0 is mapped to your
> real uid, and set up your sandbox (aka mount /dev/pts and everything
> else).
> 
> Step b.  Create a nested user namespace where your uid is identity
> mapped and run your desktop application.  You can even drop all caps 
> in
> your namespace.
> 
> Or basically:
>     unshare(CLONE_NEWUSER)
>     
>     map 0 to real_uid
>     set things up.
>     
>     unshare(CLONE_NEWUSER)
>     map real_uid to 0 (Because I am assuming we are
>                       single threaded in the nested context)
>     
>     drop caps
>     exec /path/to/my/sandboxed/application

Thanks. I'll try that.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
> Alexander Larsson <alexl@redhat.com> writes:
> 
> > On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
> > > Andy Lutomirski <luto@amacapital.net> writes:
> > > 
> > > > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
> > > > <ebiederm@xmission.com> wrote:
> > > > > Andy Lutomirski <luto@amacapital.net> writes:
> > > > > 
> > > > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
> > > > > > alexl@redhat.com> wrote:
> > > > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
> > > > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
> > > > > > > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson 
> > > > > > > > > wrote:
> > > > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy 
> > > > > > > > > > > Lutomirski 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think that this is correct.  That user 
> > > > > > > > > > > > can 
> > > > > > > > > > > > already create a
> > > > > > > > > > > > nested userns and map themselves as 0 inside 
> > > > > > > > > > > > it. 
> > > > > > > > > > > >  Then they can mount
> > > > > > > > > > > > devpts.
> > > > > > > > > > > 
> > > > > > > > > > > I don't mind if they create a container and 
> > > > > > > > > > > control 
> > > > > > > > > > > the isolated ttys in
> > > > > > > > > > > that sub container in the VPS; that's fine.  I do 
> > > > > > > > > > > 
> > > > > > > > > > > mind if they get
> > > > > > > > > > > access to the ttys in the VPS.
> > > > > > > > > > > 
> > > > > > > > > > > If you can convince me (and the rest of Linux) 
> > > > > > > > > > > that 
> > > > > > > > > > > the tty subsystem
> > > > > > > > > > > should be mountable by an unprivileged user 
> > > > > > > > > > > generally, then what you
> > > > > > > > > > > propose is OK.
> > > > > > > > > > 
> > > > > > > > > > That is controlled by the general rights to mount 
> > > > > > > > > > stuff. I.e. unless you
> > > > > > > > > > have CAP_SYS_ADMIN in the VPS container you will 
> > > > > > > > > > not be 
> > > > > > > > > > able to mount
> > > > > > > > > > devpts there. You can only do it in a subcontainer 
> > > > > > > > > > where you got
> > > > > > > > > > permissions to mount via using user namespaces.
> > > > > > > > > 
> > > > > > > > > OK let me try again.  Fine, if you want to speak 
> > > > > > > > > capabilities, you've
> > > > > > > > > given a non-root user an unexpected capability (the 
> > > > > > > > > capability of
> > > > > > > > > creating a ptmx device).  But you haven't used a 
> > > > > > > > > capability separation
> > > > > > > > > to do this, you've just hard coded it via a mount 
> > > > > > > > > parameter mechanism.
> > > > > > > > > 
> > > > > > > > > If you want to do this thing, do it properly, so it's 
> > > > > > > > > 
> > > > > > > > > acceptable to the
> > > > > > > > > whole of Linux, not a special corner case for one 
> > > > > > > > > particular type of
> > > > > > > > > container.
> > > > > > > > > 
> > > > > > > > > Security breaches are created when people code in 
> > > > > > > > > special, little used,
> > > > > > > > > corner cases because they don't get as thoroughly 
> > > > > > > > > tested 
> > > > > > > > > and inspected
> > > > > > > > > as generally applicable mechanisms.
> > > > > > > > > 
> > > > > > > > > What you want is to be able to use the tty subsystem 
> > > > > > > > > as a 
> > > > > > > > > non root user:
> > > > > > > > > fine, but set that up globally, don't hide it in 
> > > > > > > > > containers so a lot
> > > > > > > > > fewer people care.
> > > > > > > > 
> > > > > > > > I tend to agree, and not just for the tty subsystem. 
> > > > > > > >  This 
> > > > > > > > is an
> > > > > > > > attack surface issue.  With unprivileged user 
> > > > > > > > namespaces, 
> > > > > > > > unprivileged
> > > > > > > > users can create mount namespaces (probably a good 
> > > > > > > > thing 
> > > > > > > > for bind
> > > > > > > > mounts, etc), network namespaces (reasonably safe by 
> > > > > > > > themselves),
> > > > > > > > network interfaces and iptables rules (scary), fresh
> > > > > > > > instances/superblocks of some filesystems (scariness 
> > > > > > > > depends on the fs
> > > > > > > > -- tmpfs is probably fine), and more.
> > > > > > > > 
> > > > > > > > I think we should have real controls for this, and this 
> > > > > > > > is 
> > > > > > > > mostly
> > > > > > > > Eric's domain.  Eric?  A silly issue that sometimes 
> > > > > > > > prevents devpts
> > > > > > > > from being mountable isn't a real control, though.
> > > > > 
> > > > > I thought the controls for limiting how much of the userspace 
> > > > > API
> > > > > an application could use were called seccomp and seccomp2.
> > > > > 
> > > > > Do we need something like a PAM module so that we can set up 
> > > > > these
> > > > > controls during login?
> > > > > 
> > > > > > > I'm honestly surprised that non-root is allowed to mount 
> > > > > > > things in
> > > > > > > general with user namespaces. This was long disabled use 
> > > > > > > for 
> > > > > > > non-root in
> > > > > > > Fedora, but it is now enabled.
> > > > > > > 
> > > > > > > For instance, using loopback mounted files you could 
> > > > > > > probably 
> > > > > > > attack
> > > > > > > some of the less well tested filesystem implementations 
> > > > > > > by 
> > > > > > > feeding them
> > > > > > > fuzzed data.
> > > > > > > 
> > > > > > 
> > > > > > You actually can't do that right now.  Filesystems have to 
> > > > > > opt 
> > > > > > in to
> > > > > > being mounted in unprivileged user namespaces, and no 
> > > > > > filesystems with
> > > > > > backing stores have opted in.  devpts has, but it's buggy 
> > > > > > without this
> > > > > > patch IMO.
> > > > > 
> > > > > Arguably you should use two user namespaces.  The first to do 
> > > > > 
> > > > > what you
> > > > > want to as root the second to run as the uid you want to run 
> > > > > as.
> > > > > 
> > > > > > > Anyway, I don't see how this affects devpts though. If 
> > > > > > > you're 
> > > > > > > running in
> > > > > > > a container (or uncontained), as a regular users with no 
> > > > > > > mount
> > > > > > > capabilities you can already mount a devpts filesystem if 
> > > > > > > you 
> > > > > > > create a
> > > > > > > subbcontainer with user namespaces and map your uid to 0 
> > > > > > > in 
> > > > > > > the
> > > > > > > subcontainer. Then you get a new ptmx device that you can 
> > > > > > > do 
> > > > > > > whatever
> > > > > > > you want with. The mount option would let you do the 
> > > > > > > same, 
> > > > > > > except be
> > > > > > > your regular uid in the subcontainer.
> > > > > > > 
> > > > > > > The only difference outside of the subcontainer is that 
> > > > > > > if 
> > > > > > > the outer
> > > > > > > container has no uid 0 mapped, yet the user has 
> > > > > > > CAP_SYSADMIN 
> > > > > > > rights in
> > > > > > > that container. Then he can mount devpts in the outer 
> > > > > > > container where he
> > > > > > > before could only mount it in an inner container.
> > > > > > > 
> > > > > > 
> > > > > > Agreed.  Also, devpts doesn't seem scary at all to me from 
> > > > > > a 
> > > > > > userns
> > > > > > perspective.  Regular users on normal systems can already 
> > > > > > use 
> > > > > > ptmx,
> > > > > > and AFAICS basically all of the attack surface is already 
> > > > > > available
> > > > > > through the normal /dev/ptmx node.
> > > > > 
> > > > > My only real take is that there are a lot more places that 
> > > > > you 
> > > > > need to
> > > > > tweak beyond devpts.  So this patch seemed lacking and 
> > > > > boring.
> > > > > 
> > > > > Beyond that until I get the mount namespace sorted out things 
> > > > > are 
> > > > > pretty
> > > > > much in a feature freeze because I can't multitask well 
> > > > > enough to 
> > > > > do
> > > > > complicated patches and take feature patches.
> > > > > 
> > > > 
> > > > Eric, do you think you have time now to take a look at this 
> > > > patch?
> > > 
> > > I am much closer.  Escaping bind mounts is still not yet fixed 
> > > but I
> > > have code that almost works.
> > > 
> > > My gut feel still says that two user namespaces one where your 0 
> > > is
> > > mapped to your uid and a second where your uid is identity mapped 
> > > is 
> > > the
> > > preferrable configuration, and makes this patch unnecessary.
> > 
> > I don't really understand this. My usecase is that I want a desktop 
> > app
> > sandbox, it should run as the actual user that is running the 
> > graphical
> > session mapped to its real uid. In this namespace i want a /dev/pts 
> > so
> > that i can e.g. shell out to ssh and feed it a password on the tty
> > prompt or similar. And i don't want to bind-mount in the host 
> > /dev/pts,
> > because then the sandbox can read from the ttys of other apps.
> > 
> > Where does the second namespace enter into this? 
> 
> Step a.  Create create a user namespace where uid 0 is mapped to your
> real uid, and set up your sandbox (aka mount /dev/pts and everything
> else).
> 
> Step b.  Create a nested user namespace where your uid is identity
> mapped and run your desktop application.  You can even drop all caps 
> in
> your namespace.
> 
> Or basically:
>     unshare(CLONE_NEWUSER)
>     
>     map 0 to real_uid
>     set things up.
>     
>     unshare(CLONE_NEWUSER)
>     map real_uid to 0 (Because I am assuming we are
>                       single threaded in the nested context)
>     
>     drop caps
>     exec /path/to/my/sandboxed/application

Thanks. I'll try that.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>>
>>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>>> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>> > >
>>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>>> > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>> > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>>> > > > > > > wrote:
>>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>>> > > > > > > > wrote:
>>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>>> > > > > > > > > wrote:
>>> > > > > > > > > >
>>> > > > > > > > > > I don't think that this is correct.  That user can
>>> > > > > > > > > > already create a
>>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>>> > > > > > > > > >  Then they can mount
>>> > > > > > > > > > devpts.
>>> > > > > > > > >
>>> > > > > > > > > I don't mind if they create a container and control
>>> > > > > > > > > the isolated ttys in
>>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>>> > > > > > > > > mind if they get
>>> > > > > > > > > access to the ttys in the VPS.
>>> > > > > > > > >
>>> > > > > > > > > If you can convince me (and the rest of Linux) that
>>> > > > > > > > > the tty subsystem
>>> > > > > > > > > should be mountable by an unprivileged user
>>> > > > > > > > > generally, then what you
>>> > > > > > > > > propose is OK.
>>> > > > > > > >
>>> > > > > > > > That is controlled by the general rights to mount
>>> > > > > > > > stuff. I.e. unless you
>>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>>> > > > > > > > able to mount
>>> > > > > > > > devpts there. You can only do it in a subcontainer
>>> > > > > > > > where you got
>>> > > > > > > > permissions to mount via using user namespaces.
>>> > > > > > >
>>> > > > > > > OK let me try again.  Fine, if you want to speak
>>> > > > > > > capabilities, you've
>>> > > > > > > given a non-root user an unexpected capability (the
>>> > > > > > > capability of
>>> > > > > > > creating a ptmx device).  But you haven't used a
>>> > > > > > > capability separation
>>> > > > > > > to do this, you've just hard coded it via a mount
>>> > > > > > > parameter mechanism.
>>> > > > > > >
>>> > > > > > > If you want to do this thing, do it properly, so it's
>>> > > > > > > acceptable to the
>>> > > > > > > whole of Linux, not a special corner case for one
>>> > > > > > > particular type of
>>> > > > > > > container.
>>> > > > > > >
>>> > > > > > > Security breaches are created when people code in
>>> > > > > > > special, little used,
>>> > > > > > > corner cases because they don't get as thoroughly tested
>>> > > > > > > and inspected
>>> > > > > > > as generally applicable mechanisms.
>>> > > > > > >
>>> > > > > > > What you want is to be able to use the tty subsystem as a
>>> > > > > > > non root user:
>>> > > > > > > fine, but set that up globally, don't hide it in
>>> > > > > > > containers so a lot
>>> > > > > > > fewer people care.
>>> > > > > >
>>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>>> > > > > > is an
>>> > > > > > attack surface issue.  With unprivileged user namespaces,
>>> > > > > > unprivileged
>>> > > > > > users can create mount namespaces (probably a good thing
>>> > > > > > for bind
>>> > > > > > mounts, etc), network namespaces (reasonably safe by
>>> > > > > > themselves),
>>> > > > > > network interfaces and iptables rules (scary), fresh
>>> > > > > > instances/superblocks of some filesystems (scariness
>>> > > > > > depends on the fs
>>> > > > > > -- tmpfs is probably fine), and more.
>>> > > > > >
>>> > > > > > I think we should have real controls for this, and this is
>>> > > > > > mostly
>>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>>> > > > > > prevents devpts
>>> > > > > > from being mountable isn't a real control, though.
>>> > >
>>> > > I thought the controls for limiting how much of the userspace API
>>> > > an application could use were called seccomp and seccomp2.
>>> > >
>>> > > Do we need something like a PAM module so that we can set up
>>> > > these
>>> > > controls during login?
>>> > >
>>> > > > > I'm honestly surprised that non-root is allowed to mount
>>> > > > > things in
>>> > > > > general with user namespaces. This was long disabled use for
>>> > > > > non-root in
>>> > > > > Fedora, but it is now enabled.
>>> > > > >
>>> > > > > For instance, using loopback mounted files you could probably
>>> > > > > attack
>>> > > > > some of the less well tested filesystem implementations by
>>> > > > > feeding them
>>> > > > > fuzzed data.
>>> > > > >
>>> > > >
>>> > > > You actually can't do that right now.  Filesystems have to opt
>>> > > > in to
>>> > > > being mounted in unprivileged user namespaces, and no
>>> > > > filesystems with
>>> > > > backing stores have opted in.  devpts has, but it's buggy
>>> > > > without this
>>> > > > patch IMO.
>>> > >
>>> > > Arguably you should use two user namespaces.  The first to do
>>> > > what you
>>> > > want to as root the second to run as the uid you want to run as.
>>> > >
>>> > > > > Anyway, I don't see how this affects devpts though. If you're
>>> > > > > running in
>>> > > > > a container (or uncontained), as a regular users with no
>>> > > > > mount
>>> > > > > capabilities you can already mount a devpts filesystem if you
>>> > > > > create a
>>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>>> > > > > the
>>> > > > > subcontainer. Then you get a new ptmx device that you can do
>>> > > > > whatever
>>> > > > > you want with. The mount option would let you do the same,
>>> > > > > except be
>>> > > > > your regular uid in the subcontainer.
>>> > > > >
>>> > > > > The only difference outside of the subcontainer is that if
>>> > > > > the outer
>>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>>> > > > > rights in
>>> > > > > that container. Then he can mount devpts in the outer
>>> > > > > container where he
>>> > > > > before could only mount it in an inner container.
>>> > > > >
>>> > > >
>>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>>> > > > userns
>>> > > > perspective.  Regular users on normal systems can already use
>>> > > > ptmx,
>>> > > > and AFAICS basically all of the attack surface is already
>>> > > > available
>>> > > > through the normal /dev/ptmx node.
>>> > >
>>> > > My only real take is that there are a lot more places that you
>>> > > need to
>>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>>> > >
>>> > > Beyond that until I get the mount namespace sorted out things are
>>> > > pretty
>>> > > much in a feature freeze because I can't multitask well enough to
>>> > > do
>>> > > complicated patches and take feature patches.
>>> > >
>>> >
>>> > Eric, do you think you have time now to take a look at this patch?
>>>
>>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>>> have code that almost works.
>>>
>>> My gut feel still says that two user namespaces one where your 0 is
>>> mapped to your uid and a second where your uid is identity mapped is
>>> the
>>> preferrable configuration, and makes this patch unnecessary.
>>
>> I don't really understand this. My usecase is that I want a desktop app
>> sandbox, it should run as the actual user that is running the graphical
>> session mapped to its real uid. In this namespace i want a /dev/pts so
>> that i can e.g. shell out to ssh and feed it a password on the tty
>> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
>> because then the sandbox can read from the ttys of other apps.
>>
>> Where does the second namespace enter into this?
>>
>
> I think Eric is suggesting making a user namespace that maps your uid
> as 0, then making a mount namespace and mounting devpts, then making
> *another* user namespace that maps your uid (seen as 0) back to
> whatever nonzero number you want.
>
> That would probably work, but I think it's really ugly.

I just looked and the number of places where we actually care if uid 0
is mapped is very small.  Mostly just the places that have to deal with
setuid applications.  So I think the maintenance burden is much smaller
that I would have expected.

That said if we update /dev/pts to handle being mounted by a non-root
user I expect what we actually want is to use the fsuid and fsgid
of the caller of mount.  That is less code and it does the right thing
without effort, and it makes sense even outside of a user namespace
context.

Something like:

diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index add566303c68..8fdaa6740f23 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -245,13 +245,8 @@ static int mknod_ptmx(struct super_block *sb)
        struct dentry *root = sb->s_root;
        struct pts_fs_info *fsi = DEVPTS_SB(sb);
        struct pts_mount_opts *opts = &fsi->mount_opts;
-       kuid_t root_uid;
-       kgid_t root_gid;
-
-       root_uid = make_kuid(current_user_ns(), 0);
-       root_gid = make_kgid(current_user_ns(), 0);
-       if (!uid_valid(root_uid) || !gid_valid(root_gid))
-               return -EINVAL;
+       kuid_t ptmx_uid = current_fsuid();
+       kgid_t ptmx_gid = current_fsgid();
 
        mutex_lock(&d_inode(root)->i_mutex);
 
@@ -282,8 +277,8 @@ static int mknod_ptmx(struct super_block *sb)
 
        mode = S_IFCHR|opts->ptmxmode;
        init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
-       inode->i_uid = root_uid;
-       inode->i_gid = root_gid;
+       inode->i_uid = ptmx_uid;
+       inode->i_gid = ptmx_gid;
 
        d_add(dentry, inode);
 
Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Andy Lutomirski <luto@amacapital.net> writes:

> On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl@redhat.com> wrote:
>> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>>> Andy Lutomirski <luto@amacapital.net> writes:
>>>
>>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>>> > <ebiederm@xmission.com> wrote:
>>> > > Andy Lutomirski <luto@amacapital.net> writes:
>>> > >
>>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>>> > > > alexl@redhat.com> wrote:
>>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>> > > > > > <James.Bottomley@hansenpartnership.com> wrote:
>>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>>> > > > > > > wrote:
>>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>>> > > > > > > > wrote:
>>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>>> > > > > > > > > wrote:
>>> > > > > > > > > >
>>> > > > > > > > > > I don't think that this is correct.  That user can
>>> > > > > > > > > > already create a
>>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>>> > > > > > > > > >  Then they can mount
>>> > > > > > > > > > devpts.
>>> > > > > > > > >
>>> > > > > > > > > I don't mind if they create a container and control
>>> > > > > > > > > the isolated ttys in
>>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>>> > > > > > > > > mind if they get
>>> > > > > > > > > access to the ttys in the VPS.
>>> > > > > > > > >
>>> > > > > > > > > If you can convince me (and the rest of Linux) that
>>> > > > > > > > > the tty subsystem
>>> > > > > > > > > should be mountable by an unprivileged user
>>> > > > > > > > > generally, then what you
>>> > > > > > > > > propose is OK.
>>> > > > > > > >
>>> > > > > > > > That is controlled by the general rights to mount
>>> > > > > > > > stuff. I.e. unless you
>>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>>> > > > > > > > able to mount
>>> > > > > > > > devpts there. You can only do it in a subcontainer
>>> > > > > > > > where you got
>>> > > > > > > > permissions to mount via using user namespaces.
>>> > > > > > >
>>> > > > > > > OK let me try again.  Fine, if you want to speak
>>> > > > > > > capabilities, you've
>>> > > > > > > given a non-root user an unexpected capability (the
>>> > > > > > > capability of
>>> > > > > > > creating a ptmx device).  But you haven't used a
>>> > > > > > > capability separation
>>> > > > > > > to do this, you've just hard coded it via a mount
>>> > > > > > > parameter mechanism.
>>> > > > > > >
>>> > > > > > > If you want to do this thing, do it properly, so it's
>>> > > > > > > acceptable to the
>>> > > > > > > whole of Linux, not a special corner case for one
>>> > > > > > > particular type of
>>> > > > > > > container.
>>> > > > > > >
>>> > > > > > > Security breaches are created when people code in
>>> > > > > > > special, little used,
>>> > > > > > > corner cases because they don't get as thoroughly tested
>>> > > > > > > and inspected
>>> > > > > > > as generally applicable mechanisms.
>>> > > > > > >
>>> > > > > > > What you want is to be able to use the tty subsystem as a
>>> > > > > > > non root user:
>>> > > > > > > fine, but set that up globally, don't hide it in
>>> > > > > > > containers so a lot
>>> > > > > > > fewer people care.
>>> > > > > >
>>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>>> > > > > > is an
>>> > > > > > attack surface issue.  With unprivileged user namespaces,
>>> > > > > > unprivileged
>>> > > > > > users can create mount namespaces (probably a good thing
>>> > > > > > for bind
>>> > > > > > mounts, etc), network namespaces (reasonably safe by
>>> > > > > > themselves),
>>> > > > > > network interfaces and iptables rules (scary), fresh
>>> > > > > > instances/superblocks of some filesystems (scariness
>>> > > > > > depends on the fs
>>> > > > > > -- tmpfs is probably fine), and more.
>>> > > > > >
>>> > > > > > I think we should have real controls for this, and this is
>>> > > > > > mostly
>>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>>> > > > > > prevents devpts
>>> > > > > > from being mountable isn't a real control, though.
>>> > >
>>> > > I thought the controls for limiting how much of the userspace API
>>> > > an application could use were called seccomp and seccomp2.
>>> > >
>>> > > Do we need something like a PAM module so that we can set up
>>> > > these
>>> > > controls during login?
>>> > >
>>> > > > > I'm honestly surprised that non-root is allowed to mount
>>> > > > > things in
>>> > > > > general with user namespaces. This was long disabled use for
>>> > > > > non-root in
>>> > > > > Fedora, but it is now enabled.
>>> > > > >
>>> > > > > For instance, using loopback mounted files you could probably
>>> > > > > attack
>>> > > > > some of the less well tested filesystem implementations by
>>> > > > > feeding them
>>> > > > > fuzzed data.
>>> > > > >
>>> > > >
>>> > > > You actually can't do that right now.  Filesystems have to opt
>>> > > > in to
>>> > > > being mounted in unprivileged user namespaces, and no
>>> > > > filesystems with
>>> > > > backing stores have opted in.  devpts has, but it's buggy
>>> > > > without this
>>> > > > patch IMO.
>>> > >
>>> > > Arguably you should use two user namespaces.  The first to do
>>> > > what you
>>> > > want to as root the second to run as the uid you want to run as.
>>> > >
>>> > > > > Anyway, I don't see how this affects devpts though. If you're
>>> > > > > running in
>>> > > > > a container (or uncontained), as a regular users with no
>>> > > > > mount
>>> > > > > capabilities you can already mount a devpts filesystem if you
>>> > > > > create a
>>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>>> > > > > the
>>> > > > > subcontainer. Then you get a new ptmx device that you can do
>>> > > > > whatever
>>> > > > > you want with. The mount option would let you do the same,
>>> > > > > except be
>>> > > > > your regular uid in the subcontainer.
>>> > > > >
>>> > > > > The only difference outside of the subcontainer is that if
>>> > > > > the outer
>>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>>> > > > > rights in
>>> > > > > that container. Then he can mount devpts in the outer
>>> > > > > container where he
>>> > > > > before could only mount it in an inner container.
>>> > > > >
>>> > > >
>>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>>> > > > userns
>>> > > > perspective.  Regular users on normal systems can already use
>>> > > > ptmx,
>>> > > > and AFAICS basically all of the attack surface is already
>>> > > > available
>>> > > > through the normal /dev/ptmx node.
>>> > >
>>> > > My only real take is that there are a lot more places that you
>>> > > need to
>>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>>> > >
>>> > > Beyond that until I get the mount namespace sorted out things are
>>> > > pretty
>>> > > much in a feature freeze because I can't multitask well enough to
>>> > > do
>>> > > complicated patches and take feature patches.
>>> > >
>>> >
>>> > Eric, do you think you have time now to take a look at this patch?
>>>
>>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>>> have code that almost works.
>>>
>>> My gut feel still says that two user namespaces one where your 0 is
>>> mapped to your uid and a second where your uid is identity mapped is
>>> the
>>> preferrable configuration, and makes this patch unnecessary.
>>
>> I don't really understand this. My usecase is that I want a desktop app
>> sandbox, it should run as the actual user that is running the graphical
>> session mapped to its real uid. In this namespace i want a /dev/pts so
>> that i can e.g. shell out to ssh and feed it a password on the tty
>> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
>> because then the sandbox can read from the ttys of other apps.
>>
>> Where does the second namespace enter into this?
>>
>
> I think Eric is suggesting making a user namespace that maps your uid
> as 0, then making a mount namespace and mounting devpts, then making
> *another* user namespace that maps your uid (seen as 0) back to
> whatever nonzero number you want.
>
> That would probably work, but I think it's really ugly.

I just looked and the number of places where we actually care if uid 0
is mapped is very small.  Mostly just the places that have to deal with
setuid applications.  So I think the maintenance burden is much smaller
that I would have expected.

That said if we update /dev/pts to handle being mounted by a non-root
user I expect what we actually want is to use the fsuid and fsgid
of the caller of mount.  That is less code and it does the right thing
without effort, and it makes sense even outside of a user namespace
context.

Something like:

diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index add566303c68..8fdaa6740f23 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -245,13 +245,8 @@ static int mknod_ptmx(struct super_block *sb)
        struct dentry *root = sb->s_root;
        struct pts_fs_info *fsi = DEVPTS_SB(sb);
        struct pts_mount_opts *opts = &fsi->mount_opts;
-       kuid_t root_uid;
-       kgid_t root_gid;
-
-       root_uid = make_kuid(current_user_ns(), 0);
-       root_gid = make_kgid(current_user_ns(), 0);
-       if (!uid_valid(root_uid) || !gid_valid(root_gid))
-               return -EINVAL;
+       kuid_t ptmx_uid = current_fsuid();
+       kgid_t ptmx_gid = current_fsgid();
 
        mutex_lock(&d_inode(root)->i_mutex);
 
@@ -282,8 +277,8 @@ static int mknod_ptmx(struct super_block *sb)
 
        mode = S_IFCHR|opts->ptmxmode;
        init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
-       inode->i_uid = root_uid;
-       inode->i_gid = root_gid;
+       inode->i_uid = ptmx_uid;
+       inode->i_gid = ptmx_gid;
 
        d_add(dentry, inode);
 
Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
> 
> > Where does the second namespace enter into this? 
> 
> Step a.  Create create a user namespace where uid 0 is mapped to your
> real uid, and set up your sandbox (aka mount /dev/pts and everything
> else).
> 
> Step b.  Create a nested user namespace where your uid is identity
> mapped and run your desktop application.  You can even drop all caps 
> in
> your namespace.

Just tried this. Its not the nicest, and it doubles the number of
namespaces in action for each sandbox, but it does work.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
> 
> > Where does the second namespace enter into this? 
> 
> Step a.  Create create a user namespace where uid 0 is mapped to your
> real uid, and set up your sandbox (aka mount /dev/pts and everything
> else).
> 
> Step b.  Create a nested user namespace where your uid is identity
> mapped and run your desktop application.  You can even drop all caps 
> in
> your namespace.

Just tried this. Its not the nicest, and it doubles the number of
namespaces in action for each sandbox, but it does work.

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Kenton Varda]

On Thu, May 28, 2015 at 1:06 PM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
>>
>> > Where does the second namespace enter into this?
>>
>> Step a.  Create create a user namespace where uid 0 is mapped to your
>> real uid, and set up your sandbox (aka mount /dev/pts and everything
>> else).
>>
>> Step b.  Create a nested user namespace where your uid is identity
>> mapped and run your desktop application.  You can even drop all caps
>> in
>> your namespace.
>
> Just tried this. Its not the nicest, and it doubles the number of
> namespaces in action for each sandbox, but it does work.

How much overhead is involved in each user namespace? Is there any
system-wide limit on total namespaces, other than RAM? Is there
(non-negligible) CPU overhead for each syscall seeking permissions in
the namespace?

-Kenton

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Kenton Varda]

On Thu, May 28, 2015 at 1:06 PM, Alexander Larsson <alexl@redhat.com> wrote:
> On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
>>
>> > Where does the second namespace enter into this?
>>
>> Step a.  Create create a user namespace where uid 0 is mapped to your
>> real uid, and set up your sandbox (aka mount /dev/pts and everything
>> else).
>>
>> Step b.  Create a nested user namespace where your uid is identity
>> mapped and run your desktop application.  You can even drop all caps
>> in
>> your namespace.
>
> Just tried this. Its not the nicest, and it doubles the number of
> namespaces in action for each sandbox, but it does work.

How much overhead is involved in each user namespace? Is there any
system-wide limit on total namespaces, other than RAM? Is there
(non-negligible) CPU overhead for each syscall seeking permissions in
the namespace?

-Kenton

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Kenton Varda <kenton-AuYgBwuPrUQTaNkGU808tA@public.gmane.org> writes:

> On Thu, May 28, 2015 at 1:06 PM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
>>>
>>> > Where does the second namespace enter into this?
>>>
>>> Step a.  Create create a user namespace where uid 0 is mapped to your
>>> real uid, and set up your sandbox (aka mount /dev/pts and everything
>>> else).
>>>
>>> Step b.  Create a nested user namespace where your uid is identity
>>> mapped and run your desktop application.  You can even drop all caps
>>> in
>>> your namespace.
>>
>> Just tried this. Its not the nicest, and it doubles the number of
>> namespaces in action for each sandbox, but it does work.
>
> How much overhead is involved in each user namespace?

sizeof(struct user_namespace).

> Is there any system-wide limit on total namespaces, other than RAM? 

There is a system-wide maximum depth, but not count.

>  Is there
> (non-negligible) CPU overhead for each syscall seeking permissions in
> the namespace?

ns_capable(ns, X) in some cases can walk up the from a starting user
namespace to the initial user.  (The only non-constant operation I am
aware of).  However unless the user namespace depth is deep it should
still take a negligible amount of time.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Eric W. Biederman]

Kenton Varda <kenton@sandstorm.io> writes:

> On Thu, May 28, 2015 at 1:06 PM, Alexander Larsson <alexl@redhat.com> wrote:
>> On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
>>>
>>> > Where does the second namespace enter into this?
>>>
>>> Step a.  Create create a user namespace where uid 0 is mapped to your
>>> real uid, and set up your sandbox (aka mount /dev/pts and everything
>>> else).
>>>
>>> Step b.  Create a nested user namespace where your uid is identity
>>> mapped and run your desktop application.  You can even drop all caps
>>> in
>>> your namespace.
>>
>> Just tried this. Its not the nicest, and it doubles the number of
>> namespaces in action for each sandbox, but it does work.
>
> How much overhead is involved in each user namespace?

sizeof(struct user_namespace).

> Is there any system-wide limit on total namespaces, other than RAM? 

There is a system-wide maximum depth, but not count.

>  Is there
> (non-negligible) CPU overhead for each syscall seeking permissions in
> the namespace?

ns_capable(ns, X) in some cases can walk up the from a starting user
namespace to the initial user.  (The only non-constant operation I am
aware of).  However unless the user namespace depth is deep it should
still take a negligible amount of time.

Eric

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>
>> On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>>>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>>>
>>>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>>>> > <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>> > > Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>>> > >
>>>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>>>> > > > alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>> > > > > > <James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote:
>>>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>>>> > > > > > > wrote:
>>>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>>>> > > > > > > > wrote:
>>>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>>>> > > > > > > > > wrote:
>>>> > > > > > > > > >
>>>> > > > > > > > > > I don't think that this is correct.  That user can
>>>> > > > > > > > > > already create a
>>>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>>>> > > > > > > > > >  Then they can mount
>>>> > > > > > > > > > devpts.
>>>> > > > > > > > >
>>>> > > > > > > > > I don't mind if they create a container and control
>>>> > > > > > > > > the isolated ttys in
>>>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>>>> > > > > > > > > mind if they get
>>>> > > > > > > > > access to the ttys in the VPS.
>>>> > > > > > > > >
>>>> > > > > > > > > If you can convince me (and the rest of Linux) that
>>>> > > > > > > > > the tty subsystem
>>>> > > > > > > > > should be mountable by an unprivileged user
>>>> > > > > > > > > generally, then what you
>>>> > > > > > > > > propose is OK.
>>>> > > > > > > >
>>>> > > > > > > > That is controlled by the general rights to mount
>>>> > > > > > > > stuff. I.e. unless you
>>>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>>>> > > > > > > > able to mount
>>>> > > > > > > > devpts there. You can only do it in a subcontainer
>>>> > > > > > > > where you got
>>>> > > > > > > > permissions to mount via using user namespaces.
>>>> > > > > > >
>>>> > > > > > > OK let me try again.  Fine, if you want to speak
>>>> > > > > > > capabilities, you've
>>>> > > > > > > given a non-root user an unexpected capability (the
>>>> > > > > > > capability of
>>>> > > > > > > creating a ptmx device).  But you haven't used a
>>>> > > > > > > capability separation
>>>> > > > > > > to do this, you've just hard coded it via a mount
>>>> > > > > > > parameter mechanism.
>>>> > > > > > >
>>>> > > > > > > If you want to do this thing, do it properly, so it's
>>>> > > > > > > acceptable to the
>>>> > > > > > > whole of Linux, not a special corner case for one
>>>> > > > > > > particular type of
>>>> > > > > > > container.
>>>> > > > > > >
>>>> > > > > > > Security breaches are created when people code in
>>>> > > > > > > special, little used,
>>>> > > > > > > corner cases because they don't get as thoroughly tested
>>>> > > > > > > and inspected
>>>> > > > > > > as generally applicable mechanisms.
>>>> > > > > > >
>>>> > > > > > > What you want is to be able to use the tty subsystem as a
>>>> > > > > > > non root user:
>>>> > > > > > > fine, but set that up globally, don't hide it in
>>>> > > > > > > containers so a lot
>>>> > > > > > > fewer people care.
>>>> > > > > >
>>>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>>>> > > > > > is an
>>>> > > > > > attack surface issue.  With unprivileged user namespaces,
>>>> > > > > > unprivileged
>>>> > > > > > users can create mount namespaces (probably a good thing
>>>> > > > > > for bind
>>>> > > > > > mounts, etc), network namespaces (reasonably safe by
>>>> > > > > > themselves),
>>>> > > > > > network interfaces and iptables rules (scary), fresh
>>>> > > > > > instances/superblocks of some filesystems (scariness
>>>> > > > > > depends on the fs
>>>> > > > > > -- tmpfs is probably fine), and more.
>>>> > > > > >
>>>> > > > > > I think we should have real controls for this, and this is
>>>> > > > > > mostly
>>>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>>>> > > > > > prevents devpts
>>>> > > > > > from being mountable isn't a real control, though.
>>>> > >
>>>> > > I thought the controls for limiting how much of the userspace API
>>>> > > an application could use were called seccomp and seccomp2.
>>>> > >
>>>> > > Do we need something like a PAM module so that we can set up
>>>> > > these
>>>> > > controls during login?
>>>> > >
>>>> > > > > I'm honestly surprised that non-root is allowed to mount
>>>> > > > > things in
>>>> > > > > general with user namespaces. This was long disabled use for
>>>> > > > > non-root in
>>>> > > > > Fedora, but it is now enabled.
>>>> > > > >
>>>> > > > > For instance, using loopback mounted files you could probably
>>>> > > > > attack
>>>> > > > > some of the less well tested filesystem implementations by
>>>> > > > > feeding them
>>>> > > > > fuzzed data.
>>>> > > > >
>>>> > > >
>>>> > > > You actually can't do that right now.  Filesystems have to opt
>>>> > > > in to
>>>> > > > being mounted in unprivileged user namespaces, and no
>>>> > > > filesystems with
>>>> > > > backing stores have opted in.  devpts has, but it's buggy
>>>> > > > without this
>>>> > > > patch IMO.
>>>> > >
>>>> > > Arguably you should use two user namespaces.  The first to do
>>>> > > what you
>>>> > > want to as root the second to run as the uid you want to run as.
>>>> > >
>>>> > > > > Anyway, I don't see how this affects devpts though. If you're
>>>> > > > > running in
>>>> > > > > a container (or uncontained), as a regular users with no
>>>> > > > > mount
>>>> > > > > capabilities you can already mount a devpts filesystem if you
>>>> > > > > create a
>>>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>>>> > > > > the
>>>> > > > > subcontainer. Then you get a new ptmx device that you can do
>>>> > > > > whatever
>>>> > > > > you want with. The mount option would let you do the same,
>>>> > > > > except be
>>>> > > > > your regular uid in the subcontainer.
>>>> > > > >
>>>> > > > > The only difference outside of the subcontainer is that if
>>>> > > > > the outer
>>>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>>>> > > > > rights in
>>>> > > > > that container. Then he can mount devpts in the outer
>>>> > > > > container where he
>>>> > > > > before could only mount it in an inner container.
>>>> > > > >
>>>> > > >
>>>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>>>> > > > userns
>>>> > > > perspective.  Regular users on normal systems can already use
>>>> > > > ptmx,
>>>> > > > and AFAICS basically all of the attack surface is already
>>>> > > > available
>>>> > > > through the normal /dev/ptmx node.
>>>> > >
>>>> > > My only real take is that there are a lot more places that you
>>>> > > need to
>>>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>>>> > >
>>>> > > Beyond that until I get the mount namespace sorted out things are
>>>> > > pretty
>>>> > > much in a feature freeze because I can't multitask well enough to
>>>> > > do
>>>> > > complicated patches and take feature patches.
>>>> > >
>>>> >
>>>> > Eric, do you think you have time now to take a look at this patch?
>>>>
>>>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>>>> have code that almost works.
>>>>
>>>> My gut feel still says that two user namespaces one where your 0 is
>>>> mapped to your uid and a second where your uid is identity mapped is
>>>> the
>>>> preferrable configuration, and makes this patch unnecessary.
>>>
>>> I don't really understand this. My usecase is that I want a desktop app
>>> sandbox, it should run as the actual user that is running the graphical
>>> session mapped to its real uid. In this namespace i want a /dev/pts so
>>> that i can e.g. shell out to ssh and feed it a password on the tty
>>> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
>>> because then the sandbox can read from the ttys of other apps.
>>>
>>> Where does the second namespace enter into this?
>>>
>>
>> I think Eric is suggesting making a user namespace that maps your uid
>> as 0, then making a mount namespace and mounting devpts, then making
>> *another* user namespace that maps your uid (seen as 0) back to
>> whatever nonzero number you want.
>>
>> That would probably work, but I think it's really ugly.
>
> I just looked and the number of places where we actually care if uid 0
> is mapped is very small.  Mostly just the places that have to deal with
> setuid applications.  So I think the maintenance burden is much smaller
> that I would have expected.
>
> That said if we update /dev/pts to handle being mounted by a non-root
> user I expect what we actually want is to use the fsuid and fsgid
> of the caller of mount.  That is less code and it does the right thing
> without effort, and it makes sense even outside of a user namespace
> context.
>
> Something like:
>
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index add566303c68..8fdaa6740f23 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -245,13 +245,8 @@ static int mknod_ptmx(struct super_block *sb)
>         struct dentry *root = sb->s_root;
>         struct pts_fs_info *fsi = DEVPTS_SB(sb);
>         struct pts_mount_opts *opts = &fsi->mount_opts;
> -       kuid_t root_uid;
> -       kgid_t root_gid;
> -
> -       root_uid = make_kuid(current_user_ns(), 0);
> -       root_gid = make_kgid(current_user_ns(), 0);
> -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> -               return -EINVAL;
> +       kuid_t ptmx_uid = current_fsuid();
> +       kgid_t ptmx_gid = current_fsgid();
>
>         mutex_lock(&d_inode(root)->i_mutex);
>
> @@ -282,8 +277,8 @@ static int mknod_ptmx(struct super_block *sb)
>
>         mode = S_IFCHR|opts->ptmxmode;
>         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> -       inode->i_uid = root_uid;
> -       inode->i_gid = root_gid;
> +       inode->i_uid = ptmx_uid;
> +       inode->i_gid = ptmx_gid;
>
>         d_add(dentry, inode);

Apparently alexl is encountering some annoyances related to the
current workaround, and the workaround is certainly ugly.

Your proposal seems like it could break some use cases involving
fscaps on a mount or mount-like binary.

What if we change it to use the owner of the userns that owns the
current mount ns?  For anything that doesn't explicitly use
namespaces, this will be zero.  For namespace users, it should do the
right thing.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson <alexl@redhat.com> wrote:
>>> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
>>>> Andy Lutomirski <luto@amacapital.net> writes:
>>>>
>>>> > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
>>>> > <ebiederm@xmission.com> wrote:
>>>> > > Andy Lutomirski <luto@amacapital.net> writes:
>>>> > >
>>>> > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
>>>> > > > alexl@redhat.com> wrote:
>>>> > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
>>>> > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
>>>> > > > > > <James.Bottomley@hansenpartnership.com> wrote:
>>>> > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
>>>> > > > > > > wrote:
>>>> > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
>>>> > > > > > > > wrote:
>>>> > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
>>>> > > > > > > > > wrote:
>>>> > > > > > > > > >
>>>> > > > > > > > > > I don't think that this is correct.  That user can
>>>> > > > > > > > > > already create a
>>>> > > > > > > > > > nested userns and map themselves as 0 inside it.
>>>> > > > > > > > > >  Then they can mount
>>>> > > > > > > > > > devpts.
>>>> > > > > > > > >
>>>> > > > > > > > > I don't mind if they create a container and control
>>>> > > > > > > > > the isolated ttys in
>>>> > > > > > > > > that sub container in the VPS; that's fine.  I do
>>>> > > > > > > > > mind if they get
>>>> > > > > > > > > access to the ttys in the VPS.
>>>> > > > > > > > >
>>>> > > > > > > > > If you can convince me (and the rest of Linux) that
>>>> > > > > > > > > the tty subsystem
>>>> > > > > > > > > should be mountable by an unprivileged user
>>>> > > > > > > > > generally, then what you
>>>> > > > > > > > > propose is OK.
>>>> > > > > > > >
>>>> > > > > > > > That is controlled by the general rights to mount
>>>> > > > > > > > stuff. I.e. unless you
>>>> > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
>>>> > > > > > > > able to mount
>>>> > > > > > > > devpts there. You can only do it in a subcontainer
>>>> > > > > > > > where you got
>>>> > > > > > > > permissions to mount via using user namespaces.
>>>> > > > > > >
>>>> > > > > > > OK let me try again.  Fine, if you want to speak
>>>> > > > > > > capabilities, you've
>>>> > > > > > > given a non-root user an unexpected capability (the
>>>> > > > > > > capability of
>>>> > > > > > > creating a ptmx device).  But you haven't used a
>>>> > > > > > > capability separation
>>>> > > > > > > to do this, you've just hard coded it via a mount
>>>> > > > > > > parameter mechanism.
>>>> > > > > > >
>>>> > > > > > > If you want to do this thing, do it properly, so it's
>>>> > > > > > > acceptable to the
>>>> > > > > > > whole of Linux, not a special corner case for one
>>>> > > > > > > particular type of
>>>> > > > > > > container.
>>>> > > > > > >
>>>> > > > > > > Security breaches are created when people code in
>>>> > > > > > > special, little used,
>>>> > > > > > > corner cases because they don't get as thoroughly tested
>>>> > > > > > > and inspected
>>>> > > > > > > as generally applicable mechanisms.
>>>> > > > > > >
>>>> > > > > > > What you want is to be able to use the tty subsystem as a
>>>> > > > > > > non root user:
>>>> > > > > > > fine, but set that up globally, don't hide it in
>>>> > > > > > > containers so a lot
>>>> > > > > > > fewer people care.
>>>> > > > > >
>>>> > > > > > I tend to agree, and not just for the tty subsystem.  This
>>>> > > > > > is an
>>>> > > > > > attack surface issue.  With unprivileged user namespaces,
>>>> > > > > > unprivileged
>>>> > > > > > users can create mount namespaces (probably a good thing
>>>> > > > > > for bind
>>>> > > > > > mounts, etc), network namespaces (reasonably safe by
>>>> > > > > > themselves),
>>>> > > > > > network interfaces and iptables rules (scary), fresh
>>>> > > > > > instances/superblocks of some filesystems (scariness
>>>> > > > > > depends on the fs
>>>> > > > > > -- tmpfs is probably fine), and more.
>>>> > > > > >
>>>> > > > > > I think we should have real controls for this, and this is
>>>> > > > > > mostly
>>>> > > > > > Eric's domain.  Eric?  A silly issue that sometimes
>>>> > > > > > prevents devpts
>>>> > > > > > from being mountable isn't a real control, though.
>>>> > >
>>>> > > I thought the controls for limiting how much of the userspace API
>>>> > > an application could use were called seccomp and seccomp2.
>>>> > >
>>>> > > Do we need something like a PAM module so that we can set up
>>>> > > these
>>>> > > controls during login?
>>>> > >
>>>> > > > > I'm honestly surprised that non-root is allowed to mount
>>>> > > > > things in
>>>> > > > > general with user namespaces. This was long disabled use for
>>>> > > > > non-root in
>>>> > > > > Fedora, but it is now enabled.
>>>> > > > >
>>>> > > > > For instance, using loopback mounted files you could probably
>>>> > > > > attack
>>>> > > > > some of the less well tested filesystem implementations by
>>>> > > > > feeding them
>>>> > > > > fuzzed data.
>>>> > > > >
>>>> > > >
>>>> > > > You actually can't do that right now.  Filesystems have to opt
>>>> > > > in to
>>>> > > > being mounted in unprivileged user namespaces, and no
>>>> > > > filesystems with
>>>> > > > backing stores have opted in.  devpts has, but it's buggy
>>>> > > > without this
>>>> > > > patch IMO.
>>>> > >
>>>> > > Arguably you should use two user namespaces.  The first to do
>>>> > > what you
>>>> > > want to as root the second to run as the uid you want to run as.
>>>> > >
>>>> > > > > Anyway, I don't see how this affects devpts though. If you're
>>>> > > > > running in
>>>> > > > > a container (or uncontained), as a regular users with no
>>>> > > > > mount
>>>> > > > > capabilities you can already mount a devpts filesystem if you
>>>> > > > > create a
>>>> > > > > subbcontainer with user namespaces and map your uid to 0 in
>>>> > > > > the
>>>> > > > > subcontainer. Then you get a new ptmx device that you can do
>>>> > > > > whatever
>>>> > > > > you want with. The mount option would let you do the same,
>>>> > > > > except be
>>>> > > > > your regular uid in the subcontainer.
>>>> > > > >
>>>> > > > > The only difference outside of the subcontainer is that if
>>>> > > > > the outer
>>>> > > > > container has no uid 0 mapped, yet the user has CAP_SYSADMIN
>>>> > > > > rights in
>>>> > > > > that container. Then he can mount devpts in the outer
>>>> > > > > container where he
>>>> > > > > before could only mount it in an inner container.
>>>> > > > >
>>>> > > >
>>>> > > > Agreed.  Also, devpts doesn't seem scary at all to me from a
>>>> > > > userns
>>>> > > > perspective.  Regular users on normal systems can already use
>>>> > > > ptmx,
>>>> > > > and AFAICS basically all of the attack surface is already
>>>> > > > available
>>>> > > > through the normal /dev/ptmx node.
>>>> > >
>>>> > > My only real take is that there are a lot more places that you
>>>> > > need to
>>>> > > tweak beyond devpts.  So this patch seemed lacking and boring.
>>>> > >
>>>> > > Beyond that until I get the mount namespace sorted out things are
>>>> > > pretty
>>>> > > much in a feature freeze because I can't multitask well enough to
>>>> > > do
>>>> > > complicated patches and take feature patches.
>>>> > >
>>>> >
>>>> > Eric, do you think you have time now to take a look at this patch?
>>>>
>>>> I am much closer.  Escaping bind mounts is still not yet fixed but I
>>>> have code that almost works.
>>>>
>>>> My gut feel still says that two user namespaces one where your 0 is
>>>> mapped to your uid and a second where your uid is identity mapped is
>>>> the
>>>> preferrable configuration, and makes this patch unnecessary.
>>>
>>> I don't really understand this. My usecase is that I want a desktop app
>>> sandbox, it should run as the actual user that is running the graphical
>>> session mapped to its real uid. In this namespace i want a /dev/pts so
>>> that i can e.g. shell out to ssh and feed it a password on the tty
>>> prompt or similar. And i don't want to bind-mount in the host /dev/pts,
>>> because then the sandbox can read from the ttys of other apps.
>>>
>>> Where does the second namespace enter into this?
>>>
>>
>> I think Eric is suggesting making a user namespace that maps your uid
>> as 0, then making a mount namespace and mounting devpts, then making
>> *another* user namespace that maps your uid (seen as 0) back to
>> whatever nonzero number you want.
>>
>> That would probably work, but I think it's really ugly.
>
> I just looked and the number of places where we actually care if uid 0
> is mapped is very small.  Mostly just the places that have to deal with
> setuid applications.  So I think the maintenance burden is much smaller
> that I would have expected.
>
> That said if we update /dev/pts to handle being mounted by a non-root
> user I expect what we actually want is to use the fsuid and fsgid
> of the caller of mount.  That is less code and it does the right thing
> without effort, and it makes sense even outside of a user namespace
> context.
>
> Something like:
>
> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index add566303c68..8fdaa6740f23 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -245,13 +245,8 @@ static int mknod_ptmx(struct super_block *sb)
>         struct dentry *root = sb->s_root;
>         struct pts_fs_info *fsi = DEVPTS_SB(sb);
>         struct pts_mount_opts *opts = &fsi->mount_opts;
> -       kuid_t root_uid;
> -       kgid_t root_gid;
> -
> -       root_uid = make_kuid(current_user_ns(), 0);
> -       root_gid = make_kgid(current_user_ns(), 0);
> -       if (!uid_valid(root_uid) || !gid_valid(root_gid))
> -               return -EINVAL;
> +       kuid_t ptmx_uid = current_fsuid();
> +       kgid_t ptmx_gid = current_fsgid();
>
>         mutex_lock(&d_inode(root)->i_mutex);
>
> @@ -282,8 +277,8 @@ static int mknod_ptmx(struct super_block *sb)
>
>         mode = S_IFCHR|opts->ptmxmode;
>         init_special_inode(inode, mode, MKDEV(TTYAUX_MAJOR, 2));
> -       inode->i_uid = root_uid;
> -       inode->i_gid = root_gid;
> +       inode->i_uid = ptmx_uid;
> +       inode->i_gid = ptmx_gid;
>
>         d_add(dentry, inode);

Apparently alexl is encountering some annoyances related to the
current workaround, and the workaround is certainly ugly.

Your proposal seems like it could break some use cases involving
fscaps on a mount or mount-like binary.

What if we change it to use the owner of the userns that owns the
current mount ns?  For anything that doesn't explicitly use
namespaces, this will be zero.  For namespace users, it should do the
right thing.

--Andy

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On mån, 2016-03-07 at 20:59 -0800, Andy Lutomirski wrote:
> On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Andy Lutomirski <luto@amacapital.net> writes:
> > 
> Apparently alexl is encountering some annoyances related to the
> current workaround, and the workaround is certainly ugly.

It works, but it introduces an extra namespace that gets exposed to the
world, which is pretty ugly. For instance, entering the namespace
becomes hard. I can setns() into the intermediate user+mount namespace
without problems, but if i try to setns into the final user+mount ns
(it gets its own implicit mount ns) i get EPERM. I'm not sure exactly
why though...

> Your proposal seems like it could break some use cases involving
> fscaps on a mount or mount-like binary.
> 
> What if we change it to use the owner of the userns that owns the
> current mount ns?  For anything that doesn't explicitly use
> namespaces, this will be zero.  For namespace users, it should do the
> right thing.

Any of these is fine with me. One nice thing would if i could somehow
detect whether this was supported or not so that i can fall back on the
old workaround.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's an all-American guitar-strumming househusband with no name. She's a 
scantily clad impetuous former first lady who don't take no shit from 
nobody. They fight crime! 


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

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Alexander Larsson]

On mån, 2016-03-07 at 20:59 -0800, Andy Lutomirski wrote:
> On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Andy Lutomirski <luto@amacapital.net> writes:
> > 
> Apparently alexl is encountering some annoyances related to the
> current workaround, and the workaround is certainly ugly.

It works, but it introduces an extra namespace that gets exposed to the
world, which is pretty ugly. For instance, entering the namespace
becomes hard. I can setns() into the intermediate user+mount namespace
without problems, but if i try to setns into the final user+mount ns
(it gets its own implicit mount ns) i get EPERM. I'm not sure exactly
why though...

> Your proposal seems like it could break some use cases involving
> fscaps on a mount or mount-like binary.
> 
> What if we change it to use the owner of the userns that owns the
> current mount ns?  For anything that doesn't explicitly use
> namespaces, this will be zero.  For namespace users, it should do the
> right thing.

Any of these is fine with me. One nice thing would if i could somehow
detect whether this was supported or not so that i can fall back on the
old workaround.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@redhat.com            alexander.larsson@gmail.com 
He's an all-American guitar-strumming househusband with no name. She's a 
scantily clad impetuous former first lady who don't take no shit from 
nobody. They fight crime! 

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 8, 2016 at 1:16 AM, Alexander Larsson <alexl@redhat.com> wrote:
> On mån, 2016-03-07 at 20:59 -0800, Andy Lutomirski wrote:
>> On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>> > Andy Lutomirski <luto@amacapital.net> writes:
>> >
>> Apparently alexl is encountering some annoyances related to the
>> current workaround, and the workaround is certainly ugly.
>
> It works, but it introduces an extra namespace that gets exposed to the
> world, which is pretty ugly. For instance, entering the namespace
> becomes hard. I can setns() into the intermediate user+mount namespace
> without problems, but if i try to setns into the final user+mount ns
> (it gets its own implicit mount ns) i get EPERM. I'm not sure exactly
> why though...
>
>> Your proposal seems like it could break some use cases involving
>> fscaps on a mount or mount-like binary.
>>
>> What if we change it to use the owner of the userns that owns the
>> current mount ns?  For anything that doesn't explicitly use
>> namespaces, this will be zero.  For namespace users, it should do the
>> right thing.
>
> Any of these is fine with me. One nice thing would if i could somehow
> detect whether this was supported or not so that i can fall back on the
> old workaround.

I'll send a patch.

I suppose the straightforward, if slightly awkward, way to detect it
is just to try it -- create a namespace and try to mount devpts.

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

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Tue, Mar 8, 2016 at 1:16 AM, Alexander Larsson <alexl@redhat.com> wrote:
> On mån, 2016-03-07 at 20:59 -0800, Andy Lutomirski wrote:
>> On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>> > Andy Lutomirski <luto@amacapital.net> writes:
>> >
>> Apparently alexl is encountering some annoyances related to the
>> current workaround, and the workaround is certainly ugly.
>
> It works, but it introduces an extra namespace that gets exposed to the
> world, which is pretty ugly. For instance, entering the namespace
> becomes hard. I can setns() into the intermediate user+mount namespace
> without problems, but if i try to setns into the final user+mount ns
> (it gets its own implicit mount ns) i get EPERM. I'm not sure exactly
> why though...
>
>> Your proposal seems like it could break some use cases involving
>> fscaps on a mount or mount-like binary.
>>
>> What if we change it to use the owner of the userns that owns the
>> current mount ns?  For anything that doesn't explicitly use
>> namespaces, this will be zero.  For namespace users, it should do the
>> right thing.
>
> Any of these is fine with me. One nice thing would if i could somehow
> detect whether this was supported or not so that i can fall back on the
> old workaround.

I'll send a patch.

I suppose the straightforward, if slightly awkward, way to detect it
is just to try it -- create a namespace and try to mount devpts.

--Andy