hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2198) Remove the need to run NodeManager as privileged account for Windows Secure Container Executor
Date Thu, 31 Jul 2014 14:32:39 GMT

    [ https://issues.apache.org/jira/browse/YARN-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080936#comment-14080936

Vinod Kumar Vavilapalli commented on YARN-2198:

Skimmed through the Windows native code and the common changes, look fine overall. Hoping
someone with Windows knowledge ([~ivanmi]?) look at the native code and someone else ([~cnauroth]?)
at the common changes more carefully.

Reviewed the patch with focus on the YARN changes. Some comments follow..

bq. With a helper service the nodemanager no longer gets a free lunch of accessing the task
The NM never explicitly reads the stdout/stderr from the container, the streams are redirected
today to their own log files according as the user's code dictates (for e.g in linux bash
-c "user-command.sh 1> stderr 2>stdout"). Do we need to do this in the WintuilsProcessStubExecutor

The LinuxContainerExecutor reads the configuration from a container-executor.cfg. We may want
to unify the configuration for the executors if in another JIRA.

Rename hadoopwinutilsvc* interfaces, file-names, classes to be something like WindowsContainerLauncherService
or similar to be explicit?

Not sure to me from the patch as to how the service's port is configured. Is it at the start
time or through some configuration?

bq. 1. Service Access check.
Sorry for repeating what you said but if I understand correctly,  we need two things (1) restricting
users who can launch the special service and (2) restricting callers who can invoke the RPCs.
So, this is done by the combination of the OS doing the authentication and the authorization
being explicitly done by the service using the allowed list. Right?

> Remove the need to run NodeManager as privileged account for Windows Secure Container
> ----------------------------------------------------------------------------------------------
>                 Key: YARN-2198
>                 URL: https://issues.apache.org/jira/browse/YARN-2198
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: Remus Rusanu
>            Assignee: Remus Rusanu
>              Labels: security, windows
>         Attachments: YARN-2198.1.patch, YARN-2198.2.patch
> YARN-1972 introduces a Secure Windows Container Executor. However this executor requires
a the process launching the container to be LocalSystem or a member of the a local Administrators
group. Since the process in question is the NodeManager, the requirement translates to the
entire NM to run as a privileged account, a very large surface area to review and protect.
> This proposal is to move the privileged operations into a dedicated NT service. The NM
can run as a low privilege account and communicate with the privileged NT service when it
needs to launch a container. This would reduce the surface exposed to the high privileges.

> There has to exist a secure, authenticated and authorized channel of communication between
the NM and the privileged NT service. Possible alternatives are a new TCP endpoint, Java RPC
etc. My proposal though would be to use Windows LPC (Local Procedure Calls), which is a Windows
platform specific inter-process communication channel that satisfies all requirements and
is easy to deploy. The privileged NT service would register and listen on an LPC port (NtCreatePort,
NtListenPort). The NM would use JNI to interop with libwinutils which would host the LPC client
code. The client would connect to the LPC port (NtConnectPort) and send a message requesting
a container launch (NtRequestWaitReplyPort). LPC provides authentication and the privileged
NT service can use authorization API (AuthZ) to validate the caller.

This message was sent by Atlassian JIRA

View raw message