[
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: [email protected]
For additional commands, e-mail: [email protected]
