[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125408#comment-13125408
]
Luke Lu commented on MAPREDUCE-2858:
------------------------------------
bq. could you please explain the threat model ASAP so that I understand what we
are trying to prevent.
The main threat we're trying to prevent is request forgery (typically a rouge
AM trying to impersonate an admin or another user) via cookie theft or "clever"
scripting.
The proxy prevents the cookie theft for none-js cases and js whitelisting
prevents both cookie theft and request forgery via js.
Note, this is also an issue in 0.20-security releases, where a "clever" user
can use a rouge redirecting jetty in map/reduce tasks and post a shortened URL
in a help request in a bug/issue ticket. But the threat surface area is a lot
smaller than MRv2, where any node:port combination is potentially a valid URL
authority and that AMs are linked from RM.
For a more secure (preventing accidental clicks to rogue URLs) production
deployment, I recommend blocking (via firewall) external network access to all
cluster nodes except the trusted nodes (RM,NN) and only allow external http
access to AM/NM via the proxy.
I'd like to thank the Y paranoid who wanted to remain anonymous :) for helpful
discussions.
> 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
