[jira] [Updated] (CASSANDRA-8650) Creation and maintenance of roles should not require superuser status

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sam Tunnicliffe updated CASSANDRA-8650:
---------------------------------------
    Attachment: 8650.txt

A question is on which resource should these new privileges be granted? In this initial patch I've added a number of new permissions : {{CREATE_ROLE}}, {{DROP_ROLE}}, {{ALTER_ROLE}}, {{GRANT_ROLE}} & {{REVOKE_ROLE}}. As roles are not intrinsically linked to particular keyspaces or tables, it doesn't make sense to allow these permissions to be granted at those levels (what would it mean to have {{CREATE_ROLE}} permissions on a specific keyspace?). So, it is only valid to grant those permissions at the root resource level, which is enforced in the CQL syntax. Rather than follow the existing {{GRANT <permission> ON <resource> TO <grantee>}} syntax, role management privileges are grouped into a pseudo-role, {{ROLEADMIN}}, which can be granted to regular roles like so:

{code}
GRANT ROLEADMIN TO foo;
{code}

This statement enables {{foo}} and other roles granted {{foo}} to perform {{CREATE ROLE}}, {{ALTER ROLE}} & {{DROP ROLE}} statements, plus the ability to {{GRANT}} and {{REVOKE}} roles. {{foo}} (or any role it is granted to), must also have {{AUTHORIZE}} permissions on a keyspace or table to be able to grant permissions to any role created. 

Giving or taking away superuser status still requires the actor to be a superuser. {{GRANT <role> TO <grantee>}} or {{REVOKE <role> FROM <revokee>}} require superuser status if {{<role>}} has it (either directly or inherited). Likewise, the {{SUPERUSER}} option may only be used in {{CREATE ROLE <role>}} and {{ALTER ROLE <role>}} when the logged in user has superuser status. Finally, {{DROP ROLE <role>}} where {{<role>}} has superuser status also requires the logged in user to be a superuser.

Modifying other alterable options now requires only the {{ALTER_ROLE}} permission, not superuser status. For example, a user who has been granted {{ROLEADMIN}} may modify the password or login status of another role.

dtests added here: https://github.com/beobal/cassandra-dtest/tree/cassandra-8650

> Creation and maintenance of roles should not require superuser status
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-8650
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8650
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>              Labels: cql, security
>             Fix For: 3.0
>
>         Attachments: 8650.txt
>
>
> Currently, only roles with superuser status are permitted to create/drop/grant/revoke roles, which violates the principal of least privilege. In addition, in order to run {{ALTER ROLE}} statements a user must log in directly as that role or else be a superuser. This requirement increases the (ab)use of superuser privileges, especially where roles are created without {{LOGIN}} privileges to model groups of permissions granted to individual db users. In this scenario, a superuser is always required if such roles are to be granted and modified.
> We should add more granular permissions to allow administration of roles without requiring superuser status.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)