[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222610#comment-16222610
]
Jason Lowe commented on YARN-7197:
----------------------------------
Like [~ebadger], I am a bit confused on how this adds a lot of value. The only
way I see this being useful is if the blacklist consists of top-level
directories like {{/run}} and {{/etc}}. Otherwise any blacklist path that
isn't a top-level directory is probably going to fool some users into thinking
the blacklist support really does prevent the container from ever getting
access to the path. But that's not going to be the case if a parent directory
of the blacklist path is in the whitelist because the container can simply
mount above the blacklist path and still see it. And if the blacklist path
parents are not in the whitelist then why do we need the blacklist entry?
I'm still wondering what a real-world use-case for this is as it works in the
patch. The closest I've seen is [[email protected]]'s
[comment|https://issues.apache.org/jira/browse/YARN-7197?focusedCommentId=16218724&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16218724]
stating we would put some top-level paths in the blacklist and they are only
there to make a sysadmin think twice about adding something under those paths
to the whitelist. I guess that's OK, but I don't see how the blacklist adds
any value if it contains a path that isn't a top-level path.
bq. In the examples above, allowing people to read yarn system directory can
leak credentials about other users. Allowing user to mount /run/docker.socket
can let user jail break docker container to become root.
Those very same examples are why I don't see the value. IIUC these two
examples are from [this
comment|https://issues.apache.org/jira/browse/YARN-7197?focusedCommentId=16217854&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16217854].
For the first one, /mnt/hdfs/user is in the whitelist so a nefarious user can
simply mount the entire /mnt/hdfs/user hierarchy and then can access the yarn
files as Eric said. I don't see how a blacklist of /mnt/hdfs/user/yarn buys
any value at all here unless we're assuming the nefarious user isn't clever.
Similarly I don't see the point of blacklisting /run/docker.socket. Either
/run isn't in the whitelist in the first place rendering the blacklist entry
moot or /run is in the whitelist and the user can simply mount /run and access
the blacklist path. What is a use-case where the a blacklist path isn't a
top-level directory and it actually helps prevent an attack from a mildly
clever nefarious user? And if it's a top-level directory we're arguably
already covered because those paths are not in the whitelist, so this ends up
as documentation of paths we really don't want admins to configure unless they
know what's going on rather than a useful tool for admins to use for their own
paths.
If we really want to prevent access to the blacklist paths couldn't we
bind-mount a read-only empty directory or something similarly useless to the
blacklist paths? The paths will still appear in the container but won't expose
anything. Bonus points for only doing the blacklist mounts that are necessary
relative to the other mounts. Then I can see how this becomes a useful tool
for admins. The admin can allow /mnt/hdfs/user in the whitelist but users will
not be able to see anything under /mnt/hdfs/user/yarn even if they mount all of
/mnt/hdfs/user. And now the blacklist really does black out the listed paths
no matter what the user tries to do or what the whitelist contains.
> 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
>
>
> 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]
