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

["Remus Rusanu (JIRA)" <ji...@apache.org>]

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

Remus Rusanu commented on YARN-2198:
------------------------------------

> 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 existing org.apache.hadoop.util.Shell.runCommand() does read the stdout and stderr of the launched process. The WSCE should preserve this. For one the container redirection occurs not in the launched process per-se, but in the shell wrapper script, so any stdout/stderr output that occurs in the wrapper script *before* the redirect would be lost. But more importantly the NM has another user for launchers: the localizer. This runs w/o a shell wrapper script and has no stdout/stderr redirect. So all in all I think there are valid reasons to capture the stdout/stderr. It is one of my goals to make WintuilsProcessStubExecutor reuse more of the existing Shell.ShellCommandExecutor implementation, rather than implement its own execute(). 

>  (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?

That is correct. There are 3 access checks that occur:

 - task.c: ValidateImpersonateAccessCheck checks that the desired runas account is allowed to be impersonated (this includes a check against the groups/accounts explicitly denied). this covers the "restricting users who can launch the special service"
 - service.c: RpcAuthorizeCallback  checks that the caller (NM) has the permission invoke the RPC service. this covers the "restricting callers who can invoke the RPCs"
 - client.c:  RpcCall_TaskCreateAsUser has an implicit access check in which the NM validates that the RPC call is serviced by an authorized service (by specifying RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH and explicitly requesting the desired SID via pLocalSystemSid). This covers the 'mutual trust' part on the RPC call boundary (ie. is the complement of "restricting callers who can invoke the RPCs")

I will address the other comments with a newer patch, ETA Wednesday.

> 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.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
(v6.2#6252)