[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241233#comment-16241233
]
Eric Yang commented on YARN-7197:
---------------------------------
[~jlowe]
{quote}
If I'm understanding properly, we need to be worried not only about what host
path the user is trying to mount but also where they are trying to mount it
within the image? I was under the impression the contents of the image were
user-provided. If that's the case then I do not see why the user needs a
bind-mount from the host to clobber some path in the image. They could just
create the nefarious contents in the image directly. Am I misunderstanding, or
do you have an example where it is necessary?
{quote}
There were two goals that we try to solve:
# Prevent leaking host sensitive information into docker container, like
{{/etc/shadow}}, {{/etc/sssd}}.
# Prevent docker container to take control of the host, like
{{/var/run/docker.socket}}, raw devices.
Bind mount is to prevent making holes on host system. If the specified path
doesn't exist, -v flag will make the directory on host system. Bind mount will
fail to start container. Users can do almost everything inside the container,
without violation of the above rules. If they created their own socket or raw
devices in container, their creation have no side effect in the host system.
We will not prevent them from doing things like:
{code}
docker run -it -v /home/test/shadow:/etc/shadow centos:latest bash
{code}
We only prevent access, if they attempt to dance around with blacklisted items.
Given that {{/etc}}, {{/run}} are in white list, and {{/etc/shadow}},
{{/run/docker.sock}} are blacklisted.
h3. Attempt to mount black list item to same path in container:
{code}
docker run -it -v /etc/shadow:/etc/shadow centos:latest bash
{code}
System try to launch container with command that would fail:
{code}
docker run -it --mount
'type=bind,source=/var/empty/sshd,target=/etc/shadow,readonly' centos:latest
bash
{code}
h3. Hacker attempts to take control of host docker.
{code}
docker run -it -v /run/docker.sock:/run/docker.sock centos:latest bash
{code}
System will launch container with added blacklisted path:
{code}
docker run -it --mount
'type=bind,source=/var/empty/sshd,target=/run/docker.sock,readonly'
centos:latest bash
{code}
The proposal to protect remapped path will safe guard the following:
h3. Attempt to override blacklisted path to alternate location:
{code}
docker run -it -v /etc/shadow:/home/test/shadow centos:latest bash
{code}
System will launch container with command that will succeed if
{{/home/test/shadow}} doesn't exist:
{code}
docker run -it --mount
'type=bind,source=/var/empty/sshd:/home/test/shadow,readonly' centos:latest bash
{code}
h3. Attempt to mount {{/etc}} to alternate location for development purpose:
{code}
docker run -it -v /etc:/home/test/etc centos:latest bash
{code}
System will launch container with added blacklisted paths:
{code}
docker run -it -v /etc:/home/test/etc --mount
'type=bind,source=/var/empty/sshd,target=/home/test/etc/shadow,readonly'
centos:latest bash
{code}
Does this design look reasonable?
Docker image can also be regulated through trusted docker registry. This makes
degree of difficulty to crack the system harder.
> Add support for a volume blacklist for docker containers
> --------------------------------------------------------
>
> Key: YARN-7197
> URL: https://issues.apache.org/jira/browse/YARN-7197
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Reporter: Shane Kumpf
> Assignee: Eric Yang
> Attachments: YARN-7197.001.patch, YARN-7197.002.patch,
> YARN-7197.003.patch, YARN-7197.004.patch, YARN-7197.005.patch
>
>
> Docker supports bind mounting host directories into containers. Work is
> underway to allow admins to configure a whilelist of volume mounts. While
> this is a much needed and useful feature, it opens the door for
> misconfiguration that may lead to users being able to compromise or crash the
> system.
> One example would be allowing users to mount /run from a host running
> systemd, and then running systemd in that container, rendering the host
> mostly unusable.
> This issue is to add support for a default blacklist. The default blacklist
> would be where we put files and directories that if mounted into a container,
> are likely to have negative consequences. Users are encouraged not to remove
> items from the default blacklist, but may do so if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
