Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 7 Dec 2016 19:51:59 +0000 (UTC)
From: "Miklos Szegedi (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13007585.1474898892000.464144.1481140319930@Atlassian.JIRA>
In-Reply-To: <JIRA.13007585.1474898892000@Atlassian.JIRA>
References: <JIRA.13007585.1474898892000@Atlassian.JIRA> <JIRA.13007585.1474898892598@arcas>
Subject: [jira] [Commented] (YARN-5673) [Umbrella] Re-write
 container-executor to improve security, extensibility, and portability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 07 Dec 2016 19:52:02 -0000


    [ https://issues.apache.org/jira/browse/YARN-5673?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15729=
736#comment-15729736 ]=20

Miklos Szegedi commented on YARN-5673:
--------------------------------------

Thank you [~vvasudev] for the quick and detailed response! I really appreci=
ate it.
{quote}
All of these binaries will require the setuid bit to be a set which means a=
dministrators will have to set permissions and manage 4 binaries. We also h=
ave to worry about 4 binaries that can have privilege escalation as opposed=
 to one - any hot fixes for example will require all 4 binaries to be updat=
ed as opposed to just one. Interestingly you feel that administrator overhe=
ad of managing 4 binaries is worth it whereas some folks would prefer it th=
e other way round =EF=BF=BC. Do other folks feel that the multiple binaries=
 approach is the way to go?
{quote}
Yes, I absolutely agree that this is a preference question. I am not sure a=
bout the ratios though. In terms of overhead, the administrator has to enab=
le the modules in the configuration anyways. What I thought is that it is e=
asier to set the permissions using familiar Unix tools rather than looking =
up the configuration files, reading the documentation about them and enabli=
ng the required modules with the right format. I have seen in the past issu=
es with too many spaces for example.
However, please take some time to answer this one question. Let's assume, w=
e were about to design /usr/bin/at, /usr/bin/sudo and /user/bin/passwd. The=
y have about the same difference as container launching and mounting cgroup=
s. Would you design them as separate tools, or as a single binary that load=
s them separately as modules based on a configuration file and command line=
 options?
{quote}
We also have to worry about 4 binaries that can have privilege escalation a=
s opposed to one
{quote}
I think the risk of privilege escalation is proportional to the amount of c=
ode rather than the amount of binaries, so it is about the same. On the oth=
er hand packing multiple functions into the same memory space may increase =
the sum of the individual risks in case of native code.
{quote}
any hot fixes for example will require all 4 binaries to be updated as oppo=
sed to just one.=20
{quote}
(I assume that the code will be super stable :-) ...)
This was actually one question that I raised. What is the common code among=
 features separated into modules? Only if common functionality is broken, i=
t needs to be patched. I think this would be limited to auditing, logging, =
and maybe some filesystem operations that can be linked to the tools.
{quote}
Fair point. The idea here is that -
(1) Administrators will not add arbitrary modules to the module list.
(2) The posix-container-executor will give up all privileges before loading=
 the modules which don't require administrator privileges
(3) Give administrators an option to turn off modules that require administ=
rator privileges.
Would these help mitigate your concerns? The issue with the current setup i=
s that there is no clean way to enable/disable functionality that administr=
ators do not want enabled on their cluster.
{quote}
I agree, this is an issue in the current setup and yes, I think these are t=
he right design decisions. Just as a side note, I prefer privileged modules=
 be disabled by default for security and supportability reasons.
{quote}
Do you have some scenarios where container launch time has been an issue? T=
he security aspects of a long running process versus one which is invoked o=
n demand are different as well.
{quote}
I just wanted to discuss this design option early before much coding has st=
arted. If we want to use Yarn not just for long batch processing but for lo=
ts of quick requests in the future, launch time is an issue. I thought I ra=
ise pipe as an other option communicating the commands together with comman=
d line, file, and environment variables.

> [Umbrella] Re-write container-executor to improve security, extensibility=
, and portability
> -------------------------------------------------------------------------=
-----------------
>
>                 Key: YARN-5673
>                 URL: https://issues.apache.org/jira/browse/YARN-5673
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: nodemanager
>            Reporter: Varun Vasudev
>            Assignee: Varun Vasudev
>         Attachments: container-executor Re-write Design Document.pdf
>
>
> As YARN adds support for new features that require administrator privileg=
es(such as support for network throttling and docker), we=E2=80=99ve had to=
 add new capabilities to the container-executor. This has led to a recognit=
ion that the current container-executor security features as well as the co=
de could be improved. The current code is fragile and it=E2=80=99s hard to =
add new features without causing regressions. Some of the improvements that=
 need to be made are -
> *Security*
> Currently the container-executor has limited security features. It relies=
 primarily on the permissions set on the binary but does little additional =
security beyond that. There are few outstanding issues today -
> - No audit log
> - No way to disable features - network throttling and docker support are =
built in and there=E2=80=99s no way to turn them off at a container-executo=
r level
> - Code can be improved - a lot of the code switches users back and forth =
in an arbitrary manner
> - No input validation - the paths, and files provided at invocation are n=
ot validated or required to be in some specific location
> - No signing functionality - there is no way to enforce that the binary w=
as invoked by the NM and not by any other process
> *Code Issues*
> The code layout and implementation themselves can be improved. Some issue=
s there are -
> - No support for log levels - everything is logged and this can=E2=80=99t=
 be turned on or off
> - Extremely long set of invocation parameters(specifically during contain=
er launch) which makes turning features on or off complicated
> - Poor test coverage - it=E2=80=99s easy to introduce regressions today d=
ue to the lack of a proper test setup
> - Duplicate functionality - there is some amount of code duplication
> - Hard to make improvements or add new features due to the issues raised =
above
> *Portability*
>  - The container-executor mixes platform dependent APIs with platform ind=
ependent APIs making it hard to run it on multiple platforms. Allowing it t=
o run on multiple platforms also improves the overall code structure .
> One option is to improve the existing container-executor, however it migh=
t be easier to start from scratch. That allows existing functionality to be=
 supported until we are ready to switch to the new code.
> This umbrella JIRA is to capture all the work required for the new code. =
I'm going to work on a design doc for the changes - any suggestions or impr=
ovements are welcome.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org