[
https://issues.apache.org/jira/browse/YARN-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153494#comment-14153494
]
Craig Welch commented on YARN-2198:
-----------------------------------
Bringing over some comments from [YARN-1063]
When looking this over to pickup context for 2198, I noticed a couple things:
libwinutils.c CreateLogonForUser - confusing name, makes me think a new
account is being created - CreateLogonTokenForUser? LogonUser?
TestWinUtils - can we add testing specific to security?
and from [YARN-1972]
ContainerLaunch
launchContainer - nit, why "userName" here, it's user everywhere else
getLocalWrapperScriptBuilder - why not an override instead of conditional (see
below wrt WindowsContainerExecutor)
WindowsSecureContainerExecutor - I really think there should be a
"WindowsContainerExecutor" and that we should go ahead and have differences
move generally to inheritance rather than conditional (as far as
reasonable/related to the change, and incrementally as we go forward, no need
to boil the ocean, but it would be good to set a good foundation here) Windows
specific logic, secure or not, should be based in this class. If the
differences required for security specific logic are significant enough, by all
means also have a WindowsSecureContainerExecutor which inherits from
WindowsContainerExecutor. I think, as much as possible, the logic should be the
same for both - with only the security specific functionality as a delta (right
now, it looks like non-secure windows uses default for implementation, and may
differ more from the "windows secure" than it should)
> Remove the need to run NodeManager as privileged account for Windows Secure
> Container Executor
> ----------------------------------------------------------------------------------------------
>
> 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
(v6.3.4#6332)
