[
https://issues.apache.org/jira/browse/YARN-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655014#comment-13655014
]
Daryn Sharp commented on YARN-613:
----------------------------------
bq. That is true in general. And I am not sure how we can even contain such a
break-in. I suppose going the way of DataNode to start the server on privileged
ports will contain it [1]. If one can get hold of the keytab(owned by YARN
user) I suppose at that point he can launch the container-executor binary too,
which will give him root access. So it's all predicated on secure setup to not
do stupid things
Secure ports would help a bit, but it's another pain point to compensate for
weakened security.
A keytab might be leaked due to weak permissions, or maybe it's not even the
keytab in the "official" path, but a copy a SE left sitting in their home dir.
So I might or might not be the yarn user with my stolen keytab. Assuming you
are the yarn user, I'm almost positive you can't get root with the container
executor - I last looked it had a hardcoded check to reject root.
The main concern I have is any NM will have the power to forge AM tokens for
all other NMs. As the number of nodes scales in a cluster, its vulnerability
increases. All I have to do is compromise 1 node out of thousands. I can then
forge AM and container tokens, and launch jobs on the thousands of other nodes
as any arbitrary user so I can compromise those hosts too. I steal those
users' appTokens from running jobs and now I have access to hdfs and other
services. Game over.
So here's how I think we can achieve both our goals:
A node token. When the RM returns container tokens, it also provides node
tokens. The node token is for authentication, the container token authorizes
the launch request. Now you can have one AM->NM connection. You can then
decide if you want status and stop operations to authenticate and/or authorize
via other tokens like AM tokens. If so, pass those tokens in the launch
request. Now you've explicitly informed the NM of permitted (AM) tokens,
instead of giving the NM the power to fabricate other (AM) tokens.
> Create NM proxy per NM instead of per container
> -----------------------------------------------
>
> Key: YARN-613
> URL: https://issues.apache.org/jira/browse/YARN-613
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Omkar Vinit Joshi
>
> Currently a new NM proxy has to be created per container since the secure
> authentication is using a containertoken from the container.
--
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
