[
https://issues.apache.org/jira/browse/HDDS-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emil Kleszcz updated HDDS-15620:
--------------------------------
Description:
In a secure Kerberized Ozone cluster, some {{ozone admin}} read/status commands
can be executed by an authenticated user that is not configured as a full Ozone
administrator and is not a member of the configured read-only administrator
group.
Example configuration:
{code:java}
<property>
<name>ozone.security.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.authorizer.class&lt;/name>
<value>org.apache.hadoop.ozone.security.acl.OzoneNativeAuthorizer</value>
</property>
<property>
<name>ozone.administrators</name>
<value>ozone</value>
</property>
<property>
<name>ozone.readonly.administrators.groups</name>
<value>ozone-readonly-admins</value>
</property>
{code}
The tested user is authenticated with Kerberos and allowed by the
service/protocol ACLs, but is not a full admin and is not a member of
{{{}ozone-readonly-admins{}}}.
These commands succeed for the non-admin user:
{code:java}
ozone admin om roles
ozone admin scm roles
ozone admin datanode list
ozone admin safemode status
{code}
The same user is correctly denied for object access and state-changing admin
operations:
{code:java}
ozone sh key list /user/<other-user>
# PERMISSION_DENIED
ozone sh volume create /test-volume
# PERMISSION_DENIED
ozone admin safemode exit
# Access denied for user <user>. SCM superuser privilege is required.
{code}
So this does not appear to expose full admin privileges. State-changing admin
operations are denied correctly.
>From checking the source code, these read/status paths do not appear to
>perform method-level checks against either _ozone.administrators_ or
{_}ozone.readonly.administrators{_}:
* _ozone admin om roles_
** _GetServiceRolesSubcommand_
** _OzoneManagerProtocol.getServiceList()_
** _OzoneManagerRequestHandler.getServiceList()_
** _OzoneManager.getServiceList()_
* _ozone admin scm roles_
** _GetScmRatisRolesSubcommand_
** _ScmClient.getScmRoles()_
** _SCMClientProtocolServer.getScmInfo()_
* _ozone admin datanode list_
** _ListInfoSubcommand_
** _ScmClient.queryNode(...)_
** _SCMClientProtocolServer.queryNode(...)_
* _ozone admin safemode status_
** _SafeModeCheckSubcommand_
** _ScmClient.inSafeMode()_
** _SCMClientProtocolServer.inSafeMode()_
By contrast, _ozone admin safemode exit_ calls
{_}SCMClientProtocolServer.forceExitSafeMode(){_}, which checks SCM admin
privileges and denies the same user.
I also could not find direct authorization test coverage for these commands.
There are functional tests for some of them, but not tests asserting the
expected behaviour for:
* full admin
* read-only admin
* authenticated non-admin
*Clarification:*
Is this expected behaviour?
If yes, it would be useful to clarify in the documentation that some _ozone
admin_ read/status commands are available to authenticated users admitted by
the service/protocol ACLs, and are not controlled by
{_}ozone.readonly.administrators{_}. Ref.
[https://ozone.apache.org/docs/administrator-guide/configuration/security/administrators/#read-only-ozone-administrators]
If not, should these commands be protected by explicit full-admin or
read-only-admin checks?
was:
In a secure Kerberized Ozone cluster, some {{ozone admin}} read/status commands
can be executed by an authenticated user that is not configured as a full Ozone
administrator and is not a member of the configured read-only administrator
group.
Example configuration:
{code:java}
<property>
<name>ozone.security.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.authorizer.class</name>
<value>org.apache.hadoop.ozone.security.acl.OzoneNativeAuthorizer</value>
</property>
<property>
<name>ozone.administrators</name>
<value>ozone</value>
</property>
<property>
<name>ozone.readonly.administrators.groups</name>
<value>ozone-readonly-admins</value>
</property>
{code}
The tested user is authenticated with Kerberos and allowed by the
service/protocol ACLs, but is not a full admin and is not a member of
{{{}ozone-readonly-admins{}}}.
These commands succeed for the non-admin user:
{code:java}
ozone admin om roles
ozone admin scm roles
ozone admin datanode list
ozone admin safemode status
{code}
The same user is correctly denied for object access and state-changing admin
operations:
{code:java}
ozone sh key list /user/<other-user>
# PERMISSION_DENIED
ozone sh volume create /test-volume
# PERMISSION_DENIED
ozone admin safemode exit
# Access denied for user <user>. SCM superuser privilege is required.
{code}
So this does not appear to expose full admin privileges. State-changing admin
operations are denied correctly.
>From checking the source code, these read/status paths do not appear to
>perform method-level checks against either _ozone.administrators_ or
{_}ozone.readonly.administrators{_}:
* _ozone admin om roles_
** _GetServiceRolesSubcommand_
** _OzoneManagerProtocol.getServiceList()_
** _OzoneManagerRequestHandler.getServiceList()_
** _OzoneManager.getServiceList()_
* _ozone admin scm roles_
** _GetScmRatisRolesSubcommand_
** _ScmClient.getScmRoles()_
** _SCMClientProtocolServer.getScmInfo()_
* _ozone admin datanode list_
** _ListInfoSubcommand_
** _ScmClient.queryNode(...)_
** _SCMClientProtocolServer.queryNode(...)_
* _ozone admin safemode status_
** _SafeModeCheckSubcommand_
** _ScmClient.inSafeMode()_
** _SCMClientProtocolServer.inSafeMode()_
By contrast, _ozone admin safemode exit_ calls
{_}SCMClientProtocolServer.forceExitSafeMode(){_}, which checks SCM admin
privileges and denies the same user.
I also could not find direct authorization test coverage for these commands.
There are functional tests for some of them, but not tests asserting the
expected behaviour for:
* full admin
* read-only admin
* authenticated non-admin
*Clarification:*
Is this expected behaviour?
If yes, it would be useful to clarify in the documentation that some _ozone
admin_ read/status commands are available to authenticated users admitted by
the service/protocol ACLs, and are not controlled by
_ozone.readonly.administrators*. Ref.
[https://ozone.apache.org/docs/administrator-guide/configuration/security/administrators/#read-only-ozone-administrators]
If not, should these commands be protected by explicit full-admin or
read-only-admin checks?
> Ozone admin read/status commands bypass read-only admin authorization
> ---------------------------------------------------------------------
>
> Key: HDDS-15620
> URL: https://issues.apache.org/jira/browse/HDDS-15620
> Project: Apache Ozone
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Emil Kleszcz
> Priority: Major
>
> In a secure Kerberized Ozone cluster, some {{ozone admin}} read/status
> commands can be executed by an authenticated user that is not configured as a
> full Ozone administrator and is not a member of the configured read-only
> administrator group.
> Example configuration:
> {code:java}
> <property>
> <name>ozone.security.enabled</name>
> <value>true</value>
> </property>
> <property>
> <name>ozone.acl.enabled</name>
> <value>true</value>
> </property>
> <property>
> <name>ozone.acl.authorizer.class&lt;/name>
> <value>org.apache.hadoop.ozone.security.acl.OzoneNativeAuthorizer</value>
> </property>
> <property>
> <name>ozone.administrators</name>
> <value>ozone</value>
> </property>
> <property>
> <name>ozone.readonly.administrators.groups</name>
> <value>ozone-readonly-admins</value>
> </property>
> {code}
> The tested user is authenticated with Kerberos and allowed by the
> service/protocol ACLs, but is not a full admin and is not a member of
> {{{}ozone-readonly-admins{}}}.
> These commands succeed for the non-admin user:
> {code:java}
> ozone admin om roles
> ozone admin scm roles
> ozone admin datanode list
> ozone admin safemode status
> {code}
> The same user is correctly denied for object access and state-changing admin
> operations:
> {code:java}
> ozone sh key list /user/<other-user>
> # PERMISSION_DENIED
> ozone sh volume create /test-volume
> # PERMISSION_DENIED
> ozone admin safemode exit
> # Access denied for user <user>. SCM superuser privilege is required.
> {code}
> So this does not appear to expose full admin privileges. State-changing admin
> operations are denied correctly.
> From checking the source code, these read/status paths do not appear to
> perform method-level checks against either _ozone.administrators_ or
> {_}ozone.readonly.administrators{_}:
> * _ozone admin om roles_
> ** _GetServiceRolesSubcommand_
> ** _OzoneManagerProtocol.getServiceList()_
> ** _OzoneManagerRequestHandler.getServiceList()_
> ** _OzoneManager.getServiceList()_
> * _ozone admin scm roles_
> ** _GetScmRatisRolesSubcommand_
> ** _ScmClient.getScmRoles()_
> ** _SCMClientProtocolServer.getScmInfo()_
> * _ozone admin datanode list_
> ** _ListInfoSubcommand_
> ** _ScmClient.queryNode(...)_
> ** _SCMClientProtocolServer.queryNode(...)_
> * _ozone admin safemode status_
> ** _SafeModeCheckSubcommand_
> ** _ScmClient.inSafeMode()_
> ** _SCMClientProtocolServer.inSafeMode()_
> By contrast, _ozone admin safemode exit_ calls
> {_}SCMClientProtocolServer.forceExitSafeMode(){_}, which checks SCM admin
> privileges and denies the same user.
> I also could not find direct authorization test coverage for these commands.
> There are functional tests for some of them, but not tests asserting the
> expected behaviour for:
> * full admin
> * read-only admin
> * authenticated non-admin
> *Clarification:*
> Is this expected behaviour?
> If yes, it would be useful to clarify in the documentation that some _ozone
> admin_ read/status commands are available to authenticated users admitted by
> the service/protocol ACLs, and are not controlled by
> {_}ozone.readonly.administrators{_}. Ref.
> [https://ozone.apache.org/docs/administrator-guide/configuration/security/administrators/#read-only-ozone-administrators]
> If not, should these commands be protected by explicit full-admin or
> read-only-admin checks?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
