hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Kumpf (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7430) User and Group mapping are incorrect in docker container
Date Wed, 08 Nov 2017 14:04:00 GMT

    [ 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:

This is not true, see the following examples:

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.

[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)

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.

[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

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' ... 

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.

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.

Docker does not make any change to the file permission.

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


USER foo

COPY run.sh /

CMD /run.sh

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

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

View raw message