[
https://issues.apache.org/jira/browse/YARN-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243031#comment-16243031
]
Eric Yang commented on YARN-7430:
---------------------------------
[[email protected]]
{quote}
Hey Eric Yang, I'm not sure that's the case. Without the user related flag,
privileged or not, the process in the container will run as whatever user was
specified in the image.
{quote}
This is not true, see the following examples:
{code}
HW13750:~ eyang$ docker run -it --privileged centos:latest bash
[root@317212a5fa9a /]# id
uid=0(root) gid=0(root) groups=0(root)
HW13750:~ eyang$ docker run -it --user=501:501 centos:latest bash
bash-4.2$ id
uid=501 gid=501 groups=501
HW13750:~ eyang$ docker run -it --privileged --user=501:501 centos:latest bash
bash-4.2$ id
uid=501 gid=501 groups=501
{code}
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}
This leads to permission denied related issues with the localized resources and
launch scripts.
{quote}
If the localized resources are owned by QA user, and docker mounts the
localized resources with the same permission when it was generated in host.
Docker does not make any change to the file permission. Here is a sample:
{code}
[root@eyang-1 ~]# ls -l /tmp/shadow
-rw-r--r--. 1 501 501 855 Nov 7 17:31 /tmp/shadow
[root@eyang-1 ~]# docker run -it --privileged --user=501:501 -v
/tmp/shadow:/etc/shadow centos:latest bash
bash-4.2$ ls -l /etc|grep shadow
----------. 1 root root 279 Sep 11 15:52 gshadow
----------. 1 root root 270 Sep 11 15:52 gshadow-
-rw-r--r--. 1 501 501 855 Nov 7 17:31 shadow
----------. 1 root root 397 Sep 11 15:53 shadow-
bash-4.2$ exit
exit
[root@eyang-1 ~]# docker run -it --user=501:501 -v /tmp/shadow:/etc/shadow
centos:latest bash
bash-4.2$ ls -l /etc/shadow
-rw-r--r--. 1 501 501 855 Nov 7 17:31 /etc/shadow
{code}
The existing implementation has two incorrect assumptions that created security
hole. First, the primary group of the user process is root for non-privileged
container, and second is handling of the ownership permission of localized
resources. It would be safer to mount system config as read-only than enabling
template logic to generate local resources that depends on system umask, and
launching (root) user to do the work. This is the opportunity to correct the
mistakes.
> 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]
