[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238528#comment-16238528
]
Jason Lowe commented on YARN-7197:
----------------------------------
Thanks for updating the patch!
bq. Container-Executor has no prior knowledge of the object type in container
image.
I'm not proposing container-executor know what the object type is in the image,
rather I'm proposing it check the object type on the host. If the type in the
host is a file and in the image it's a dir or vice-versa then it's going to
fail anyway even if it's not blacklisted because we can't mix and match between
dir and non-dir types. (file vs. character device does seem to work, however.)
bq. Directory is the only type that will slip through, and we replace the black
list item with empty directory.
I'm not sure I understand what you mean by "slip through" here.
One of the original blacklist examples you gave above showed /run/docker.socket
in the blacklist, and that's not a directory. That's going to prevent any
mounting above that path because as soon as it tries to mount a directory onto
/run/docker.socket it's going to explode. Similarly the unit test uses
/etc/shadow as an example blacklist path. That prevents mounting /etc into a
container even if /etc is in the whitelist because the container will fail as
soon as Docker tries to mount a directory onto the /etc/shadow file. Going a
directory-only route is preventing any parent directory of a non-directory
blacklisted path from being in the whitelist. Unless that's addressed, we
might as well only support host directories in the blacklist.
bq. We have a universally empty directory for prevent jailbreak, and there is
no universally empty file/socket for prevent jailbreak.
It is trivial to create these, they do not need to exist outside of the YARN
installation. The nodemanager could create a file in /tmp on startup, chmod it
to a public file, and voila -- universal empty file that can be reused across
containers. Or the container-executor could create an empty file within the
container's tmp under its working directory and mount that, which makes it
per-container and gets automatically cleaned up by YARN when the container
exits. Lots of ways to solve this problem.
In the patch, the starts_with method does not need to compute the length of
both strings and figure out which to use. It only needs to compute the length
of the prefix string. strncmp(a, b, strlen(a)) is guaranteed to not be zero if
strlen(b) < strlen(a).
It doesn't look like we allocate nearly enough space for tmp_buffer_2 here
since we're not accounting for all of the hardcoded text or terminating NUL:
{code}
tmp_buffer_2 = (char *) alloc_and_clear_memory(strlen(empty_dir) +
strlen(mount_target) + strlen(bind_mount), sizeof(char));
sprintf(tmp_buffer_2, "type=bind,source=%s,target=%s,readonly",
empty_dir, mount_target);
quote_and_append_arg(&tmp_buffer, &tmp_buffer_size, "--mount ",
tmp_buffer_2);
{code}
> 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
> Priority: Major
> 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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
