You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Craig Welch (JIRA)" <ji...@apache.org> on 2014/10/01 01:10:36 UTC

[jira] [Commented] (YARN-2198) Remove the need to run NodeManager as privileged account for Windows Secure Container Executor

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

Craig Welch commented on YARN-2198:
-----------------------------------

-re pom.xml - maybe I'm just confused, I saw a reference to this in the pom and assumed it needed to be somewhere in the project, I see it builds fine, so I guess no worries there.

TestWinUtils - so what I had in mind was mocking the native bit and having some tests for the proper behavior of the java components under various conditions - i realize this won't test the native code, which is significant, but it will test the java code for expected native code behavior, and there's non-trivial java code, strikes me as possible/worthwhile

WindowsSecureContainerExecutor - understandable as a tactical approach but I'm concerned with leaving it that way - among other things, there is quite a lot more testing opportunity with non-secure code paths as they will be exercised much more frequently in testing (doubly so with reference to your comment above...), by having the non-secure and secure line up more the secure path will end up being higher quality as most of it's codepaths will see a good deal more use/exercise/testing, especially when new functionality is added.  Also, changes going forward should require less effort if the windows path is mostly shared between secure and unsecure execution

> 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)