[jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server group as a server-group-scoped role leaks information

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814592#comment-12814592 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

This can't yet be reproduced on any EAP 6.2.0.ERx release, as it depends on a relatively new upstream commit. That's also why I'm only including a short description.

If a user in a server-group-scoped role tries to :remove a server-group that she has no permissions to, she gets a bad error message. Instead of "not found", the error message says "permission denied", effectively leaking the information that the server group exists.

Again, this can't be reproduced on any ERx release; in fact, on the last ERx release, which at this time is ER5, this works perfectly fine.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira