[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123160#comment-13123160
]
Robert Joseph Evans commented on MAPREDUCE-2858:
------------------------------------------------
At Arun's request I am posting the design comments that Luke started on before
he left for IBM.
{quote}
In MRv2, while the system servers (ResourceManager (RM), NodeManager (NM) and
NameNode (NN)) run as "trusted"
system users, the application masters (AM) run as users who submit the
application. While this offers great flexibility
to run multiple version of mapreduce frameworks (including their UI) on the
same Hadoop cluster, it has significant
implication for the security of webapps (Please do not discuss specific
vulnerabilities here).
Requirements:
0. Secure authentication for AM (for app/job level ACLs).
1. Webapp security should be optional via site configuration.
2. Support existing pluggable single sign on mechanisms.
3. Should not require per app/user configuration for deployment.
4. Should not require special site-wide DNS configuration for deployment.
Proposed design/solution/advisory:
0. The webapp security is turned on by a configuration property:
yarn.server.app-proxy, which is a comma separated list
of host:port addresses. e.g., app-proxy1.cluster1.company.com:8181
1. If any app proxy (AP) is configured, RM will use one of the APs to construct
links for AM webapps. e.g.,
http://app-proxy1.cluster1.company.com:8181/yarn/:app_id/:am_uri.
2. People are advised against visiting a link that points to a random/unknown
host:port in the cluster.
3. AP runs as a system user and acts as an authentication server and pass the
request (:am_uri) and the user.name to
corresponding AMs.
4. AM verifies AP requests by checking whether the request IP address matches
the configured AP list.
5. AP runs as a share-nothing server that gets (and caches) the :app_id to AM
mapping from RM.
6. RM verifies AP requests by checking whether the request IP address matches
the configured AP list.
7. Harden (check referrer etc.) system webapps (run as system user (hadoop,
hdfs or mapred etc.) inside ResourceManager
(RM), NodeManager (NM) and AppProxy (AP) against XSS.
{quote}
{quote}
A brief design note on javascript whitelisting AM proxy (AP):
1. At mapreduce build time, write a program to generate crypto signatures (say
SHA-1) of the content of the script
elements. Since the style of of js usage in MRv2 is fairly standard, this
captures 99.9% of the use cases.
2. At AP start up time, the whitelist of the signatures are loaded in a hashmap.
3. At serving time, the AP fetches pages from AMs and compute the signatures of
the script content (filtering out
anything in the on* attributes as well.) and lookup the hashmap. If all the
script content is whitelisted, AP pass the
page through, otherwise, a UI is displayed with button asking user/admin to
confirm or deny the content.
{quote}
> MRv2 WebApp Security
> --------------------
>
> Key: MAPREDUCE-2858
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2858
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: applicationmaster, mrv2, security
> Affects Versions: 0.23.0
> Reporter: Luke Lu
> Assignee: Luke Lu
> Priority: Blocker
> Fix For: 0.23.0
>
>
> In MRv2, while the system servers (ResourceManager (RM), NodeManager (NM) and
> NameNode (NN)) run as "trusted"
> system users, the application masters (AM) run as users who submit the
> application. While this offers great flexibility
> to run multiple version of mapreduce frameworks (including their UI) on the
> same Hadoop cluster, it has significant
> implication for the security of webapps (Please do not discuss company
> specific vulnerabilities here).
> Requirements:
> # Secure authentication for AM (for app/job level ACLs).
> # Webapp security should be optional via site configuration.
> # Support existing pluggable single sign on mechanisms.
> # Should not require per app/user configuration for deployment.
> # Should not require special site-wide DNS configuration for deployment.
> This the top jira for webapp security. A design doc/notes of threat-modeling
> and counter measures will be posted on the wiki.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
