hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remus Rusanu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2198) Remove the need to run NodeManager as privileged account for Windows Secure Container Executor
Date Tue, 30 Sep 2014 19:25:34 GMT

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

Remus Rusanu commented on YARN-2198:

[~cwelch]: thanks for the review! I will address many of the comments with new patch, meantime
some reply on issues I won't address:

> pom.xml - don’t see a /etc/hadoop or a wsce-site.xml, missed?
RR: Not sure what you mean. Do you expect a default wcse-site.xml in hadoop-common/src/conf

> return (parent == null || parent2f.exists() || mkdirs(parent)) && (mkOneDir(p2f)
|| p2f.isDirectory());
> so, I don't get this logic, & believe it will fail if the path exists and is not
a directory. Why not just do if p2f doesn't exist mkdirs(p2f)? seems much simpler, and drops
the need for mkOneDir
RR: This is actually the result of a problem Kevin hit during test deployments when NM has
access to child dirs but is access denied to parent dirs. Old NM code would attempt to mkdir
ever dir in the parent path, all the way to /. With existing dirs with access denied, this
would fail, hence the need for my change. There is already a check in the unmodified code
for the parent existing and not being a dir, couple of lines above my change.

> TestWinUtils:  can we add testing specific to security?
RR: I would like to add some, but is not at all easy. The core tenet of the WSCE is the elevated
privilege required for S4U impersonation and having tests depend on that would pose many problems
(false failures). Basically, starting the hadoopwinutilsvc service on the test box is unfeasable.

> WindowsSecureContainerExecutor - I really think there should be a "WindowsContainerExecutor"
RR: While I agree that the class architecture separation of secure vs. non-secure and Windows
vs. Linux leaves room for improvement, it is not my goal with these JIRAs to address that
problem. In fact I do have an explicit opposite mandate, to disturb all the non-secure code
paths as little as possible, to minimize regression risks.

> 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.delta.10.patch, YARN-2198.1.patch, YARN-2198.2.patch,
YARN-2198.3.patch, YARN-2198.delta.4.patch, YARN-2198.delta.5.patch, YARN-2198.delta.6.patch,
YARN-2198.delta.7.patch, YARN-2198.separation.patch, YARN-2198.trunk.10.patch, YARN-2198.trunk.4.patch,
YARN-2198.trunk.5.patch, YARN-2198.trunk.6.patch, YARN-2198.trunk.8.patch, YARN-2198.trunk.9.patch
> YARN-1972 introduces a Secure Windows Container Executor. However this executor requires
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