[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238617#comment-16238617
]
Eric Yang commented on YARN-7197:
---------------------------------
Hi [~jlowe], thank you for the review.
{quote}
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.
{quote}
Explode might be exaggeration. OS prevents the system call from succeeding,
and Docker translate the system exit code with a verbose message. This does
not cause any harm to OS. "Slip through" means mounting jailbreak directory to
target path without OS denied the mount. In the unit test,
{{test_docker_run_banned_mounts}} demonstrated that we can white list /etc, and
black list a child directory (result in mounting a empty directory) and any
file type (they are blocked by OS system call). YARN will clean up container
regardless successful creation or not. Therefore, additional code to check for
something that OS also have check point seems redundant.
{quote}
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.
{quote}
File creation is easy, and it is easy to get it wrong too. Someone on the host
OS might add additional files into files in /tmp or get erased by accident.
The default umask might not be the same as OS default, therefore extra
ownership system calls are required to secure the newly created files. Those
operation can slow down the system. Therefore, I decided to let OS system call
handle mismatch system call instead of adding more logic that might contain
even more holes.
{quote}
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:
{quote}
I think {{%s}} is extra characters counted toward required length for NULL.
> 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: [email protected]
For additional commands, e-mail: [email protected]
