[
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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
