Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D17B3200D33 for ; Wed, 25 Oct 2017 01:08:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D0116160BF2; Tue, 24 Oct 2017 23:08:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 228901609C8 for ; Wed, 25 Oct 2017 01:08:07 +0200 (CEST) Received: (qmail 41062 invoked by uid 500); 24 Oct 2017 23:08:07 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 41051 invoked by uid 99); 24 Oct 2017 23:08:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2017 23:08:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 7990DC3A0F for ; Tue, 24 Oct 2017 23:08:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id suB_OMLf0WVu for ; Tue, 24 Oct 2017 23:08:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 7B1A75FB5C for ; Tue, 24 Oct 2017 23:08:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 4C5EAE0EF0 for ; Tue, 24 Oct 2017 23:08:04 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id B7F88212FD for ; Tue, 24 Oct 2017 23:08:01 +0000 (UTC) Date: Tue, 24 Oct 2017 23:08:01 +0000 (UTC) From: "Eric Yang (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (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: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 24 Oct 2017 23:08:09 -0000 [ https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217854#comment-16217854 ] Eric Yang edited comment on YARN-7197 at 10/24/17 11:07 PM: ------------------------------------------------------------ [~ebadger] You are correct on all points, and mounting parent directory will allow container to include directories that are supposedly in the banned list. File system ACL is the only protection to verify uid:gid are indeed authorized to access the included area. The black list is designed to filter out more sinister attack against the system. For example, system admin configures: {code} white-listed-read-write: /mnt/hdfs/user black-listed: /mnt/hdfs/user/yarn {code} This will prevent naughty junior developer from doing: {code} docker run -u yarn:yarn -it -v /mnt/hdfs/user/yarn:/tmp centos:latest bash {code} and this works: {code} docker run -u 501:501 -it -v /mnt/hdfs/user:/home centos:latest bash {code} The black list feature is not designed to make a subdirectory disappear. Docker still depends on file system acl to enforce security. This feature is only good for blocking a certain system directories from developers to protect host OS and Hadoop. This is also the reason that system admin keep black list secrets from naughty developers. was (Author: eyang): [~ebadger] You are correct on all points, and mounting parent directory will allow container to include directories that are supposedly in the banned list. File system ACL is the only protection to verify uid:gid are indeed authorized to access the included area. The black list is designed to filter out more sinister attack against the system. For example, system admin configures: {code} white-listed-read-write: /mnt/hdfs/user black-listed: /mnt/hdfs/user/yarn {code} This will prevent aughty junior developer from doing: {code} docker run -u yarn:yarn -it -v /mnt/hdfs/user/yarn:/tmp centos:latest bash {code} and this works: {code} docker run -u 501:501 -it -v /mnt/hdfs/user:/home centos:latest bash {code} The black list feature is not designed to make a subdirectory disappear. Docker still depends on file system acl to enforce security. This feature is only good for blocking a certain system directories from developers to protect host OS and Hadoop. This is also the reason that system admin keep black list secrets from naughty developers. > 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: yarn-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: yarn-issues-help@hadoop.apache.org