hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Lu (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2858) MRv2 WebApp Security
Date Mon, 17 Oct 2011 16:32:11 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128984#comment-13128984

Luke Lu commented on MAPREDUCE-2858:

bq. How do you purport to even find the JavaScript? I don't believe you can write an ad-hoc
parser that detects all known ways of embedding JavaScript.

This is a good point. The scanner needs to be aggressive (false positive is OK) to cover all
script cases: anything in between script/object/embed tags, any on*|codebase|src|href attributes,
while considering charset/encoding of the response. That's why typical HTML parsers are not
suitable for this task. The scanner needs to be carefully reviewed. Fortunately, it's pretty
short as it doesn't try to do any remotely as ambitious as Caja, which ha numerous security
bugs over the years. As I mentioned, a trivial scanner that always return true for #maybeUnsafe
is acceptable. 

bq.  having a whitelisted set of ApplicationMaster jars is the only real way to achieve this.

Again, whitelisting AM jars is complementary to the proxy. But it's not sufficient for real
world usage, as there'll be too many jars to review and extremely inconvenient/counter-productive
for cluster/cloud/grid usage.

bq.  If we can't do a whitelist of binaries, we should always generate the interstitial when
the visitor doesn't match the submitter.

+1. I personally would recommend this even with whitelisted binaries and log every action
(visitor username, webapp username, visitor choice (proceed, view source, strip (non-whitelisted)
scripts (may break content) etc).
> 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
> 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


View raw message