Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 4 Nov 2017 00:01:06 +0000 (UTC)
From: "Eric Yang (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13102363.1505418463000.148383.1509753666612@Atlassian.JIRA>
In-Reply-To: <JIRA.13102363.1505418463000@Atlassian.JIRA>
References: <JIRA.13102363.1505418463000@Atlassian.JIRA> <JIRA.13102363.1505418463901@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-7197) Add support for a volume blacklist
 for docker containers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 04 Nov 2017 00:01:15 -0000


    [ https://issues.apache.org/jira/browse/YARN-7197?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16238=
617#comment-16238617 ]=20

Eric Yang commented on YARN-7197:
---------------------------------

Hi [~jlowe], thank you for the review. =20

{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.so=
cket 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 directo=
ry onto /run/docker.socket it's going to explode. Similarly the unit test u=
ses /etc/shadow as an example blacklist path. That prevents mounting /etc i=
nto 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 fil=
e.=20
{quote}

Explode might be exaggeration.  OS prevents the system call from succeeding=
, and Docker translate the system exit code with a verbose message.  This d=
oes not cause any harm to OS.  "Slip through" means mounting jailbreak dire=
ctory 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 b=
lack 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 contain=
er regardless successful creation or not.  Therefore, additional code to ch=
eck 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 YAR=
N installation. The nodemanager could create a file in /tmp on startup, chm=
od it to a public file, and voila =E2=80=93 universal empty file that can b=
e 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 wh=
en 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 acci=
dent.  The default umask might not be the same as OS default, therefore ext=
ra ownership system calls are required to secure the newly created files.  =
Those operation can slow down the system.  Therefore, I decided to let OS s=
ystem call handle mismatch system call instead of adding more logic that mi=
ght 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 NU=
L:
{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 u=
nderway to allow admins to configure a whilelist of volume mounts. While th=
is is a much needed and useful feature, it opens the door for misconfigurat=
ion that may lead to users being able to compromise or crash the system.=20
> One example would be allowing users to mount /run from a host running sys=
temd, and then running systemd in that container, rendering the host mostly=
 unusable.
> This issue is to add support for a default blacklist. The default blackli=
st would be where we put files and directories that if mounted into a conta=
iner, 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org