[
https://issues.apache.org/jira/browse/YARN-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle Leckie updated YARN-1063:
------------------------------
Description:
h1. Summary:
Securing a Hadoop cluster requires constructing some form of security boundary
around the processes executed in YARN containers. Isolation based on Windows
user isolation seems most feasible. This approach is similar to the approach
taken by the existing LinuxContainerExecutor. The current patch to winutils.exe
adds the ability to create a process as a domain user.
h1. Alternative Methods considered:
h2. Process rights limited by security token restriction:
On Windows access decisions are made by examining the security token of a
process. It is possible to spawn a process with a restricted security token.
Any of the rights granted by SIDs of the default token may be restricted. It is
possible to see this in action by examining the security tone of a sandboxed
process launch be a web browser. Typically the launched process will have a
fully restricted token and need to access machine resources through a dedicated
broker process that enforces a custom security policy. This broker process
mechanism would break compatibility with the typical Hadoop container process.
The Container process must be able to utilize standard function calls for disk
and network IO. I performed some work looking at ways to ACL the local files to
the specific launched without granting rights to other processes launched on
the same machine but found this to be an overly complex solution.
h2. Relying on APP containers:
Recent versions of windows have the ability to launch processes within an
isolated container. Application containers are supported for execution of WinRT
based executables. This method was ruled out due to the lack of official
support for standard windows APIs. At some point in the future windows may
support functionality similar to BSD jails or Linux containers, at that point
support for containers should be added.
h1. Create As User Feature Description:
h2. Usage:
A new sub command was added to the set of task commands. Here is the syntax:
winutils task createAsUser [TASKNAME] [USERNAME] [COMMAND_LINE]
Some notes:
* The username specified is in the format of "user@domain"
* The machine executing this command must be joined to the domain of the user
specified
* The domain controller must allow the account executing the command access to
the user information. For this join the account to the predefined group labeled
"Pre-Windows 2000 Compatible Access"
* The account running the command must have several rights on the local
machine. These can be managed manually using secpol.msc:
** "Act as part of the operating system" - SE_TCB_NAME
** "Replace a process-level token" - SE_ASSIGNPRIMARYTOKEN_NAME
** "Adjust memory quotas for a process" - SE_INCREASE_QUOTA_NAME
* The launched process will not have rights to the desktop so will not be able
to display any information or create UI.
* The launched process will have no network credentials. Any access of network
resources that requires domain authentication will fail.
h2. Implementation:
Winutils performs the following steps:
# Enable the required privileges for the current process.
# Register as a trusted process with the Local Security Authority (LSA).
# Create a new logon for the user passed on the command line.
# Load/Create a profile on the local machine for the new logon.
# Create a new environment for the new logon.
# Launch the new process in a job with the task name specified and using the
created logon.
# Wait for the JOB to exit.
h2. Future work:
The following work was scoped out of this check in:
* Support for non-domain users or machine that are not domain joined.
* Support for privilege isolation by running the task launcher in a high
privilege service with access over an ACLed named pipe.
was:Task isolation requires the ability to launch tasks in the context of a
particular domain user.
> Winutils needs ability to create task as domain user
> ----------------------------------------------------
>
> Key: YARN-1063
> URL: https://issues.apache.org/jira/browse/YARN-1063
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: nodemanager
> Affects Versions: trunk-win
> Environment: Windows
> Reporter: Kyle Leckie
> Labels: security
> Fix For: trunk-win
>
> Attachments: YARN-732.patch
>
>
> h1. Summary:
> Securing a Hadoop cluster requires constructing some form of security
> boundary around the processes executed in YARN containers. Isolation based on
> Windows user isolation seems most feasible. This approach is similar to the
> approach taken by the existing LinuxContainerExecutor. The current patch to
> winutils.exe adds the ability to create a process as a domain user.
> h1. Alternative Methods considered:
> h2. Process rights limited by security token restriction:
> On Windows access decisions are made by examining the security token of a
> process. It is possible to spawn a process with a restricted security token.
> Any of the rights granted by SIDs of the default token may be restricted. It
> is possible to see this in action by examining the security tone of a
> sandboxed process launch be a web browser. Typically the launched process
> will have a fully restricted token and need to access machine resources
> through a dedicated broker process that enforces a custom security policy.
> This broker process mechanism would break compatibility with the typical
> Hadoop container process. The Container process must be able to utilize
> standard function calls for disk and network IO. I performed some work
> looking at ways to ACL the local files to the specific launched without
> granting rights to other processes launched on the same machine but found
> this to be an overly complex solution.
> h2. Relying on APP containers:
> Recent versions of windows have the ability to launch processes within an
> isolated container. Application containers are supported for execution of
> WinRT based executables. This method was ruled out due to the lack of
> official support for standard windows APIs. At some point in the future
> windows may support functionality similar to BSD jails or Linux containers,
> at that point support for containers should be added.
> h1. Create As User Feature Description:
> h2. Usage:
> A new sub command was added to the set of task commands. Here is the syntax:
> winutils task createAsUser [TASKNAME] [USERNAME] [COMMAND_LINE]
> Some notes:
> * The username specified is in the format of "user@domain"
> * The machine executing this command must be joined to the domain of the user
> specified
> * The domain controller must allow the account executing the command access
> to the user information. For this join the account to the predefined group
> labeled "Pre-Windows 2000 Compatible Access"
> * The account running the command must have several rights on the local
> machine. These can be managed manually using secpol.msc:
> ** "Act as part of the operating system" - SE_TCB_NAME
> ** "Replace a process-level token" - SE_ASSIGNPRIMARYTOKEN_NAME
> ** "Adjust memory quotas for a process" - SE_INCREASE_QUOTA_NAME
> * The launched process will not have rights to the desktop so will not be
> able to display any information or create UI.
> * The launched process will have no network credentials. Any access of
> network resources that requires domain authentication will fail.
> h2. Implementation:
> Winutils performs the following steps:
> # Enable the required privileges for the current process.
> # Register as a trusted process with the Local Security Authority (LSA).
> # Create a new logon for the user passed on the command line.
> # Load/Create a profile on the local machine for the new logon.
> # Create a new environment for the new logon.
> # Launch the new process in a job with the task name specified and using the
> created logon.
> # Wait for the JOB to exit.
> h2. Future work:
> The following work was scoped out of this check in:
> * Support for non-domain users or machine that are not domain joined.
> * Support for privilege isolation by running the task launcher in a high
> privilege service with access over an ACLed named pipe.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
