[
https://issues.apache.org/jira/browse/RANGER-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kirby zhou updated RANGER-3635:
-------------------------------
Description:
A rough conclusion:
If a Ranger client passes the authentication, drops hadoop.auth cookie and
keeps requesting every few minutes, the client will never log out. Even though
the original Kerberos ticket and hadoop.auth token have expired.
Dropping the hadoop.auth cookie can easily happen by default settings. Because
the out-box setting will cause illegal domain= to appear in cookies, common
clients will discard this cookie at this time.
Details:
Now, a successful REST-API call will set 2 cookies:
A. "hadoop.auth" by RangerKrbFilter::createAuthCookie
B. "RANGERADMINSESSIONID" by tomcat http session system
Only B works, and configuration property
"ranger.admin.kerberos.token.valid.seconds" is meaningless for REST-API.
Explains:
By default, "hadoop.auth" will have a domain set by conf
"ranger.admin.kerberos.cookie.domain" which have a default value "" in
"ranger-admin-site.xml". So it sets "; Domain= " in http response by the
following codelet:
{code:java}
if (domain != null) {
sb.append("; Domain=").append(domain);
} {code}
But "; Domain= " is invalid in a lot of client systems due to security
concerns.
So, "hadoop.auth" cookie is ignored by them.
But tomcat will set a session by cookie "RANGERADMINSESSIONID", our client
didn't find anything unusual. And session timeout (default 60m)is controlled by
web.xml which is not in out conf/ directory. So our defuat conf
ranger.admin.kerberos.token.valid.seconds = 30s (second) is meaningless.
Unfortunately there is some security risk with session mechanism. Apache Tomcat
session timeout mainly occurs due to longer idle sessions.
So if we auth a client by kerberos, the session mechanism can lead it keep
login by ever. Even the kerberos ticket is outdated.
Example:
{code:java}
]$ curl -v -c cookies -u: --negotiate --resolve
kirbytest01.sa:6080:10.10.137.131
'http://kirbytest01.sa:6080/service/plugins/secure/policies/download/hdfsdev'
...
< HTTP/1.1 200 OK
< WWW-Authenticate: Negotiate
oYHtMIHqoAMKAQChCwYJKoZIhvcSAQIComoEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qdo2oEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qd
* skipped cookie with bad tailmatch domain:
< Set-Cookie:
hadoop.auth="u=freeman&p=freeman@SA&t=kerberos&e=1645499352543&s=IHkDgmx2XOY+gqXA28wFRPwl8HnLyFkI3Ky9ifIzyyY=";
Path=/; Domain=; Expires=Tue, 22-Feb-2022 03:09:12 GMT; HttpOnly
* Replaced cookie RANGERADMINSESSIONID="1D2AD847382F6FCC66E37C63533FA297" for
domain kirbytest01.sa, path /, expire 0
< Set-Cookie: RANGERADMINSESSIONID=1D2AD847382F6FCC66E37C63533FA297; Path=/;
HttpOnly
]$ cat coookies
# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
#HttpOnly_kirbytest01.sa FALSE / FALSE 0
RANGERADMINSESSIONID 1D2AD847382F6FCC66E37C63533FA297
]$ watch -n 10 curl -v -b cookies --resolve kirbytest01.sa:6080:10.10.137.131
'http://kirbytest01.sa:6080/service/plugins/se^Cre/policies/download/hdfsdev'
-o /dev/null
200 OK ## forever
{code}
was:
Now, a successful REST-API call will set 2 cookies:
A. "hadoop.auth" by RangerKrbFilter::createAuthCookie
B. "RANGERADMINSESSIONID" by tomcat http session system
Only B works, and configuration property
"ranger.admin.kerberos.token.valid.seconds" is meaningless for REST-API.
Explains:
By default, "hadoop.auth" will have a domain set by conf
"ranger.admin.kerberos.cookie.domain" which have a default value "" in
"ranger-admin-site.xml". So it sets "; Domain= " in http response by the
following codelet:
{code:java}
if (domain != null) {
sb.append("; Domain=").append(domain);
} {code}
But "; Domain= " is invalid in a lot of client systems due to security
concerns.
So, "hadoop.auth" cookie is ignored by them.
But tomcat will set a session by cookie "RANGERADMINSESSIONID", our client
didn't find anything unusual. And session timeout (default 60m)is controlled by
web.xml which is not in out conf/ directory. So our defuat conf
ranger.admin.kerberos.token.valid.seconds = 30s (second) is meaningless.
Unfortunately there is some security risk with session mechanism. Apache Tomcat
session timeout mainly occurs due to longer idle sessions.
So if we auth a client by kerberos, the session mechanism can lead it keep
login by ever. Even the kerberos ticket is outdated.
Example:
{code:java}
]$ curl -v -c cookies -u: --negotiate --resolve
kirbytest01.sa:6080:10.10.137.131
'http://kirbytest01.sa:6080/service/plugins/secure/policies/download/hdfsdev'
...
< HTTP/1.1 200 OK
< WWW-Authenticate: Negotiate
oYHtMIHqoAMKAQChCwYJKoZIhvcSAQIComoEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qdo2oEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qd
* skipped cookie with bad tailmatch domain:
< Set-Cookie:
hadoop.auth="u=freeman&p=freeman@SA&t=kerberos&e=1645499352543&s=IHkDgmx2XOY+gqXA28wFRPwl8HnLyFkI3Ky9ifIzyyY=";
Path=/; Domain=; Expires=Tue, 22-Feb-2022 03:09:12 GMT; HttpOnly
* Replaced cookie RANGERADMINSESSIONID="1D2AD847382F6FCC66E37C63533FA297" for
domain kirbytest01.sa, path /, expire 0
< Set-Cookie: RANGERADMINSESSIONID=1D2AD847382F6FCC66E37C63533FA297; Path=/;
HttpOnly
]$ cat coookies
# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
#HttpOnly_kirbytest01.sa FALSE / FALSE 0
RANGERADMINSESSIONID 1D2AD847382F6FCC66E37C63533FA297
]$ watch -n 10 curl -v -b cookies --resolve kirbytest01.sa:6080:10.10.137.131
'http://kirbytest01.sa:6080/service/plugins/se^Cre/policies/download/hdfsdev'
-o /dev/null
200 OK ## forever
{code}
Summary: REST-API security risk, kerberos cookie hadoop.auth is broken,
timeout mech of alternative session is broken. (was: REST-API security risk,
cookie hadoop.auth is often ignored, web session works instead, timeout is
broken.)
> REST-API security risk, kerberos cookie hadoop.auth is broken, timeout mech
> of alternative session is broken.
> -------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-3635
> URL: https://issues.apache.org/jira/browse/RANGER-3635
> Project: Ranger
> Issue Type: Bug
> Components: admin
> Affects Versions: 3.0.0, 2.2.0, 2.3.0
> Reporter: kirby zhou
> Priority: Major
>
> A rough conclusion:
> If a Ranger client passes the authentication, drops hadoop.auth cookie and
> keeps requesting every few minutes, the client will never log out. Even
> though the original Kerberos ticket and hadoop.auth token have expired.
>
> Dropping the hadoop.auth cookie can easily happen by default settings.
> Because the out-box setting will cause illegal domain= to appear in cookies,
> common clients will discard this cookie at this time.
>
> Details:
>
> Now, a successful REST-API call will set 2 cookies:
> A. "hadoop.auth" by RangerKrbFilter::createAuthCookie
> B. "RANGERADMINSESSIONID" by tomcat http session system
>
> Only B works, and configuration property
> "ranger.admin.kerberos.token.valid.seconds" is meaningless for REST-API.
>
> Explains:
>
> By default, "hadoop.auth" will have a domain set by conf
> "ranger.admin.kerberos.cookie.domain" which have a default value "" in
> "ranger-admin-site.xml". So it sets "; Domain= " in http response by the
> following codelet:
>
> {code:java}
> if (domain != null) {
> sb.append("; Domain=").append(domain);
> } {code}
> But "; Domain= " is invalid in a lot of client systems due to security
> concerns.
> So, "hadoop.auth" cookie is ignored by them.
> But tomcat will set a session by cookie "RANGERADMINSESSIONID", our client
> didn't find anything unusual. And session timeout (default 60m)is controlled
> by web.xml which is not in out conf/ directory. So our defuat conf
> ranger.admin.kerberos.token.valid.seconds = 30s (second) is meaningless.
> Unfortunately there is some security risk with session mechanism. Apache
> Tomcat session timeout mainly occurs due to longer idle sessions.
> So if we auth a client by kerberos, the session mechanism can lead it keep
> login by ever. Even the kerberos ticket is outdated.
>
> Example:
>
>
> {code:java}
> ]$ curl -v -c cookies -u: --negotiate --resolve
> kirbytest01.sa:6080:10.10.137.131
> 'http://kirbytest01.sa:6080/service/plugins/secure/policies/download/hdfsdev'
> ...
> < HTTP/1.1 200 OK
> < WWW-Authenticate: Negotiate
> oYHtMIHqoAMKAQChCwYJKoZIhvcSAQIComoEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qdo2oEaGBmBgkqhkiG9xIBAgICAG9XMFWgAwIBBaEDAgEPokkwR6ADAgEXokAEPufXDNr8Trp6CFHt1x/cszrgBFvRJVpBOM+YQZjXQBkTwo08e3cDHYvbBgUBfR0ZSSGEPBShs4OZaoW+x4qd
> * skipped cookie with bad tailmatch domain:
> < Set-Cookie:
> hadoop.auth="u=freeman&p=freeman@SA&t=kerberos&e=1645499352543&s=IHkDgmx2XOY+gqXA28wFRPwl8HnLyFkI3Ky9ifIzyyY=";
> Path=/; Domain=; Expires=Tue, 22-Feb-2022 03:09:12 GMT; HttpOnly
> * Replaced cookie RANGERADMINSESSIONID="1D2AD847382F6FCC66E37C63533FA297" for
> domain kirbytest01.sa, path /, expire 0
> < Set-Cookie: RANGERADMINSESSIONID=1D2AD847382F6FCC66E37C63533FA297; Path=/;
> HttpOnly
> ]$ cat coookies
> # Netscape HTTP Cookie File
> # https://curl.haxx.se/docs/http-cookies.html
> # This file was generated by libcurl! Edit at your own risk.
> #HttpOnly_kirbytest01.sa FALSE / FALSE 0
> RANGERADMINSESSIONID 1D2AD847382F6FCC66E37C63533FA297
> ]$ watch -n 10 curl -v -b cookies --resolve kirbytest01.sa:6080:10.10.137.131
> 'http://kirbytest01.sa:6080/service/plugins/se^Cre/policies/download/hdfsdev'
> -o /dev/null
> 200 OK ## forever
> {code}
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
