[
https://issues.apache.org/jira/browse/HADOOP-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832580#comment-16832580
]
Daryn Sharp commented on HADOOP-16287:
--------------------------------------
We need this, but -1 on one very seemingly simple change noted below this list.
Cursory review:
# I'd like to see this be a unique filter, not a subclass of
{{KerberosAuthenticationHandler}}, since there's no reason for it to be
specific to any given authentication type. Ideally it should be an enforced
filter installed at the tail of the filter chain.
# Should be much cheaper to use {{request.getParameter("doAs")}} versus
manually re-parsing the query string.
# Returning no meaningful status message with the forbidden response isn't
useful. Might not have to catch the exception from {{ProxyUsers.authorize}}.
I think the exception mappings will convert it to a forbidden response and also
afford apps to ability encode the remote exception in the response payload.
Test it out though.
-1 on returning a new auth cookie as the impersonated user. It's insanely
dangerous and will create bugs and/or security holes. The auth cookie must be
the authenticated user. Let's explore the unintended side effects.
The auth cookie is equivalent to hard authentication (typically kerberos unless
there's a custom auth filter). That's very important because impersonation and
management operations (ie. token ops) can only be performed via hard
authentication or auth cookie. The impersonated user did not authenticate so
they _must not_ be granted an auth cookie.
Cookie aware clients including but not limited to {{AuthenticatedURL}} and by
extension the rest-based kms client, and perhaps things like Hue, may be
unexpectedly impacted. Consider if "proxyuser" impersonates "user1". This patch
will cause a cookie for user1 to be used for all subsequent operations. Now a
few bad things can happen:
# "proxyuser" attempts another operation as user1. Instead of passing an auth
cookie for proxyuser, it passes one for user1 and fails because user1 is likely
not a proxy user and thus cannot proxy to itself.
# "proxyuser" now attempts to impersonate user2. Uses the auth cookie for
user1 which hopefully fails because user1 likely isn't a proxy user too.
# "proxyuser" attempts to perform an operation as itself but instead will do
it as user1.
Best case, all these should fail. Worst case, the potential for very creative
abuse can elevate privileges esp. with sloppy proxy user configurations which
apparently are more common than I thought.
> KerberosAuthenticationHandler Trusted Proxy Support for Knox
> ------------------------------------------------------------
>
> Key: HADOOP-16287
> URL: https://issues.apache.org/jira/browse/HADOOP-16287
> Project: Hadoop Common
> Issue Type: New Feature
> Components: auth
> Affects Versions: 3.2.0
> Reporter: Prabhu Joseph
> Assignee: Prabhu Joseph
> Priority: Major
> Attachments: HADOOP-16287-001.patch
>
>
> Knox passes doAs with end user while accessing RM, WebHdfs Rest Api.
> Currently KerberosAuthenticationHandler sets the remote user to Knox. Need
> Trusted Proxy Support by reading doAs query parameter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
