[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=12815527#comment-12815527 ] 

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

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

I don't believe this should be "high" severity. See https://bugzilla.redhat.com/show_bug.cgi?id=1015524#c1 for an explanation of why the other server groups are not addressable. It's really not an attempt to hide sensitive data. It's an unsuccessful attempt to provide a coherent view of the resource tree to the user. Ideally these resources would be addressable but not readable, but we can't do that for 6.2 without introducing too much risk for breaking things in the console.

No argument that if the resource is not supposed to be addressable a permission denied response is not correct.
                
> 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