Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 8 Nov 2017 14:04:00 +0000 (UTC)
From: "Shane Kumpf (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13115733.1509652717000.181625.1510149840227@Atlassian.JIRA>
In-Reply-To: <JIRA.13115733.1509652717000@Atlassian.JIRA>
References: <JIRA.13115733.1509652717000@Atlassian.JIRA> <JIRA.13115733.1509652717882@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-7430) User and Group mapping are incorrect
 in docker container
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 08 Nov 2017 14:04:10 -0000


    [ https://issues.apache.org/jira/browse/YARN-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243982#comment-16243982 ] 

Shane Kumpf commented on YARN-7430:
-----------------------------------

{quote}
This is not true, see the following examples:
{quote}

I guess I don't understand what those examples are trying to convey. I become root with or without privileged if I don't supply the --user/uid flags. The centos image has no USER entry, so this is what I would expect.

{code}
[foo@localhost ~]$ docker run -it centos:latest bash
[root@00f0c3ac84cf /]# id
uid=0(root) gid=0(root) groups=0(root)

[foo@localhost ~]$ docker run -it --privileged centos:latest bash
[root@955eb326cb66 /]# id
uid=0(root) gid=0(root) groups=0(root)
{code}

With user remapping disabled, which is the default, the {{docker run}} form is different than what you are testing. It is {{docker run --detach=true --user=<username> ...}} (not --user=<uid>) - that doesn't seem to suffer from the issue you call out where the primary group is missing, since the container fails to start if the user doesn't exist in the container.

{code:java}
[foo@localhost ~]$ docker run -it --user=foo centos:latest bash
docker: Error response from daemon: linux spec user: unable to find user foo: no matching entries in passwd file
{code}

At this point, I'm confused on exactly what conditions result in this exploit. Can you clarify? I've yet to see the form you tested occur anywhere. I see the following: 

* Without user remapping: docker run --user='skumpf' ... 
* With user remapping: docker run --user='501:502' --group-add='502' ... 

{quote}
When --privileged=true and --user are set, the container is started with root privilegs and drop to the user privileges. If there is sticky bits binary in the container file system, it is possible for process to resume root privileges. If the container filesystem can be tainted by pushing custom image with sticky bits, then jailbreak is possible.
{quote}

I don't understand how that is exploitable. The ENTRYPOINT/CMD will be run as the user supplied by YARN. If the ENTRYPOINT/CMD is a setuid binary that gives that user root access in the container, this becomes true, but I can do that without a privileged container.

{quote}
Docker does not make any change to the file permission.
{quote}

That's my point. Consider the following Dockerfile:
{code}
FROM centos

USERADD foo

USER foo

COPY run.sh /

CMD /run.sh
{code}

I then submit an application as user "skumpf" that uses the image above. The localized resources and container launch script is owned by "skumpf" on the host and will be bind mounted into the container. With the current behavior using {{docker run}} and {{--user}} the the launch script will be ran as "skumpf" (per our docs skumpf must exist in the container and have the same UID as the host), even in the privileged case. If we remove {{--user}} from {{docker run}} in the the privileged case, then now the the launch script will be executed by user "foo" in my container, using whatever UID "foo" has in the container. User "foo" in the container does not have permission to execute the launch script owned by "skumpf" and thus the container will fail to launch with a permission denied error. We need the {{--user/uid}} option even if privileged is requested, because without it, we have no idea what user the container will run as.

> User and Group mapping are incorrect in docker container
> --------------------------------------------------------
>
>                 Key: YARN-7430
>                 URL: https://issues.apache.org/jira/browse/YARN-7430
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: security, yarn
>    Affects Versions: 2.9.0, 3.0.0
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Blocker
>         Attachments: YARN-7430.001.patch
>
>
> In YARN-4266, the recommendation was to use -u [uid]:[gid] numeric values to enforce user and group for the running user.  In YARN-6623, this translated to --user=test --group-add=group1.  The code no longer enforce group correctly for launched process.  
> In addition, the implementation in YARN-6623 requires the user and group information to exist in container to translate username and group to uid/gid.  For users on LDAP, there is no good way to populate container with user and group information. 


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org