Bug 1019784 - RBAC: Trying to remove a server group as a server-group-scoped role leaks information
RBAC: Trying to remove a server group as a server-group-scoped role leaks inf...
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ER7
: EAP 6.2.0
Assigned To: Brian Stansberry
Ladislav Thon
Russell Dickenson
Depends On:
  Show dependency treegraph
Reported: 2013-10-16 08:03 EDT by Ladislav Thon
Modified: 2014-05-26 21:28 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-15 11:22:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2317 Major Resolved Trying to remove a server group as a server-group-scoped role leaks information 2016-09-22 08:47 EDT

  None (edit)
Description Ladislav Thon 2013-10-16 08:03:19 EDT
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.
Comment 1 JBoss JIRA Server 2013-10-16 08:09:28 EDT
Ladislav Thon <lthon@redhat.com> made a comment on jira WFLY-2317

I believe that this commit might be the cause: https://github.com/wildfly/wildfly/commit/6e35f084deeeb1df3c555bcdda121b7cd157cea2 At least it is the reason why I wrote that test case.
Comment 2 Brian Stansberry 2013-10-16 16:07:17 EDT
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.
Comment 3 Ladislav Thon 2013-10-17 02:20:59 EDT
If this is not supposed to hide sensitive data (which I believed is the case), then I'm lowering the severity to medium. Still, :read-resource and :remove on a non-addressable resource should give the same answer.
Comment 4 Ladislav Thon 2013-10-17 02:31:42 EDT
One more thing -- if we have these resources non-addressable now and we'll try to make them addressable & non-readable in the future, that might be considered a regression by some customers. I'm not sure what my feelings about that would be.
Comment 5 Ladislav Thon 2013-10-17 04:35:28 EDT
This is reproducible on ER6 using the same instructions as in the upstream issue. Copying those instructions here for reference.

On a freshly unpacked EAP 6.2.0.ER6 with added "admin" user into domain/configuration/mgmt-users.properties, the problem can be reproduced like this:

[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/include=user-admin:add(name=admin, type=user)
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
[1] ^C
[2] ./bin/jboss-cli.sh -c --user=admin --password=XXX

What does that mean? The "NewRole" role is scoped to the "main-server-group" server group and can't see the "other-server-group" group. When doing "/server-group=other-server-group:read-resource", this is correctly enforced and the output looks like this:

    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
    "rolled-back" => true

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:

    "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

I expect the error message to be completely the same as in previous case, not leaking any information that the "other-server-group" group actually exists.
Comment 10 JBoss JIRA Server 2013-10-18 06:56:58 EDT
Ladislav Thon <lthon@redhat.com> made a comment on jira WFLY-2317

I've rebased the branch and submitted a pull request (the branch/PR contains some more tests than this one). In the PR, I changed the test to pass and added a comment to explain that it shouldn't be Outcome.UNAUTHORIZED but Outcome.HIDDEN.
Comment 11 JBoss JIRA Server 2013-10-21 14:50:45 EDT
Brian Stansberry <brian.stansberry@redhat.com> updated the status of jira WFLY-2317 to Coding In Progress
Comment 13 Ladislav Thon 2013-11-04 05:46:22 EST
Verified with EAP 6.2.0.ER7.

Note You need to log in before you can comment on or make changes to this bug.