hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-15162) UserGroupInformation.createRemoteUser hardcode authentication method to SIMPLE
Date Mon, 08 Jan 2018 18:20:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-15162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316725#comment-16316725
] 

Eric Yang commented on HADOOP-15162:
------------------------------------

Hi [~jlowe],  Webhdfs and YARN allows impersonation through usage of ?user.name=foobar in
HTTP URL.  This allows SIMPLE security mode to run as any other user without check.  If the
cluster is configured with Linux Container Executor, then it can be carry out as a privileges
escalation exploit in combination with vulnerability found in YARN-7590.

Trust and verify are very important processes to enforce authentication security.  Server
side must do either username/password challenge or token validation to enforce security like
you said.  In Hadoop implementation of SIMPLE security, there is no authentication challenge
in form of username/password prompt or token challenge to client.  Therefore, Hadoop doAs
call trusts everyone who claims to be someone else when using SIMPLE security.

The fix must happen to intercepting RPC or HTTP requests to add authentication challenge to
enforce security.  createRemoteUser should be intelligent to know the preference of the authentication
to apply to avoid security holes.  Without addressing these issues, we are encouraging developer
to write code such as:

{code}
    UserGroupInformation proxyUser;
    UserGroupInformation ugi;
    String remoteUser = request.getRemoteUser();
    try {
      if (UserGroupInformation.isSecurityEnabled()) {
        proxyUser = UserGroupInformation.getLoginUser();
        ugi = UserGroupInformation
            .createProxyUser(remoteUser, proxyUser);
      } else {
        ugi = UserGroupInformation.createRemoteUser(remoteUser);
      }
      return ugi;
    } catch (IOException e) {
      throw new AccessControlException(e.getCause());
    }
{code}

If security is not enabled, allow proxy without checking for the current user is allowed to
proxy.  Unfortunately, SIMPLE security is tight to no security due to improper interpretation
in isSecurityEnabled method since Hadoop 0.20 security releases.  

If authentication are in place, server side code can be simplified to:

{code}
    UserGroupInformation proxyUser;
    UserGroupInformation ugi;
    String remoteUser = request.getRemoteUser();
    try {
      ugi = UserGroupInformation.createRemoteUser(remoteUser);
      return ugi;
    } catch (IOException e) {
      throw new AccessControlException(e.getCause());
    }
{code}

createRemoteUser(String user), can get the current login user, then createProxyUser.  At minimum
proxy user ACL list will be verified for simple security to set a security perimeter, and
combined with authentication challenge to provide simple security.   

Client code can assign any arbitrary user, and trigger authentication challenge to occur when
communicate with the server side.  This is happening when Kerberos security is enabled.  It
would be nice if the same practice can apply to SIMPLE security without open up security holes
regardless Kerberos security is enabled or not.

The very first design of Hadoop security was attempting to solve replay attack.  Kerberos
security or a combination of proxy user/host ACL list can both serve the same purpose.  For
some reason, during the implementation, Kerberos and proxy ACL list became only enforced when
Kerberos security is enabled.  Kerberos and proxy ACL are in fact redundant checks.  This
left SIMPLE security to be completely open, no security and no proxy check.

If developers blindly utilized the current implementation of UserGroupInformation.createRemoteUser(remoteUser);,
part of Hadoop can be opened up to run without any security without anyone knowing.  This
is not good security practice, hence, we probably want to mitigate this risk by improving
the logic in createRemoteUser and review if there is a need to revise SIMPLE security definition.

If isSecurityEnabled() is based on hadoop.security.authentication==null, then the implementation
of HTTP basic + proxy ACL and Kerberos could be two methods that enforce security.  This provide
a way to apply security measure on cloud without deploying Kerberos.

> UserGroupInformation.createRemoteUser hardcode authentication method to SIMPLE
> ------------------------------------------------------------------------------
>
>                 Key: HADOOP-15162
>                 URL: https://issues.apache.org/jira/browse/HADOOP-15162
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>            Reporter: Eric Yang
>
> {{UserGroupInformation.createRemoteUser(String user)}} is hard coded Authentication method
to SIMPLE by HADOOP-10683.  This by passed proxyuser ACL check, isSecurityEnabled check, and
allow caller to impersonate as anyone.  This method could be abused in the main code base,
which can cause part of Hadoop to become insecure without proxyuser check for both SIMPLE
or Kerberos enabled environment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message